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ABSTRACT 


Internetworking  is  the  ability  to  seamlessly  interconnect  multiple  dissimilar 
networks  globally  using  the  Internet  (Brutzman,  96).  In  order  to  achieve  this 
network,  technology  needs  to  provide  speeds  which  will  allow  the  network  to 
function  properly.  Many  applications  which  are  used  on  this  network  demand  a 
high  bandwidth  to  perform  effectively. 

This  thesis  presents  an  analysis  of  Basic  Rate  Interface  (BRI)  Integrated 
Services  Digital  Network  (ISDN)  as  a  data  link  technology  for  extending  Local- 
Area  Network  (LAN)  connectivity.  Hardware  and  software  capabilities  are 
presented  in  detail.  A  representative  “ISDN  user  needs  analysis”  is  also 
provided.  A  study  is  made  of  an  ISDN  installation  and  implementation  to 
determine  if  ISDN  is  a  viable  solution  to  extending  LAN  connectivity. 

Considerations  of  particular  importance  include  Internet  Protocol(IP) 
compatibility,  bonding  separate  channels  to  act  as  a  single  128  Kbps  logical 
channel,  and  native  support  for  IP  multicast  addressing.  Experimental  results 
indicate  that  ISDN  meets  most  essential  requirements. 
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L  INTRODUCTION 


A.  PURPOSE  OF  THESIS 

Internetworking  is  the  ability  to  seamlessly  interconnect  multiple  dissimilar 
networks  globally  using  the  Internet  (Brutzman,  96).  In  order  to  achieve  this  network, 
data  Unks  need  to  provide  speeds  which  allow  applications  to  function  properly.  Many 
important  networked  applications  require  high  bandwidth  to  perform  effectively. 

This  thesis  presents  an  analysis  of  Basic  Rate  Interfece  (BRI)  Integrated  Services 
Digital  Network  (ISDN)  as  a  data  link  technology  for  extending  Local-Area  Network 
(LAN)  connectivity.  Hardware  and  Software  capabilities  are  presented  in  detail.  A 
representative  ISDN  user  needs  analysis  is  also  provided.  We  then  evaluate  the  practical 
employment  of  ISDN  in  the  Systems  Technology  Lab  (STL)  in  Root  Hall  to  determine  if 
ISDN  is  a  viable  solution. 

Considerations  of  particular  importance  include  Internet  Protocol  (IP) 
compatibility,  bonding  separate  channels  to  act  as  a  single  128  Kbps  logical  channel,  and 
native  support  for  IP  multicast  addressing.  Experiment  results  indicate  that  ISDN  meets 
most  essential  requirements. 

B.  MOTIVATION 

Many  articles  have  been  written  on  ISDN  stating  that  the  acron}^!  stands  for  “It 
Still  Does  Nothing.”  ISDN  has  been  in  existence  for  nearly  ten  years  but  its  slow 
adoption  has  meant  that  ISDN  still  remains  a  mystery  to  many.  For  most  of  those  ten 
years,  it  has  been  a  proprietary  implementation  by  the  different  telephone  companies. 
There  were  no  standards  in  place.  This  meant  that  different  companies  made  products 
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that  supported  different  features  of  ISDN  and  were  not  interoperable  with  other  ISDN 
products. 

Over  the  past  few  years,  technology  literature  has  claimed  that  ISDN  has 
improved.  The  telephone  companies  are  beginning  to  understand  the  technology  that 
they  are  providing  and  are  capable  of  trouble  shooting  problems.  Standards  are  being 
made  to  make  ISDN  and  ISDN  products  interoperable.  (Ginsberg,  95) 

Many  research  analysts  believe  however  that  the  improvements  have  come  too 
late.  They  predict  that  up-and-coming  technologies  such  as  cable  modems  and 
Asymmetric  Data  Service  Line  (ADSL)  will  make  ISDN  obsolete  (Leeds,  96).  Both 
technologies  offer  speeds  many  times  that  of  ISDN  and  wonder  why  anyone  would 
bother  with  ISDN. 

This  thesis  will  determine  whether  ISDN  is  of  immediate  practical  use.  ISDN 
needs  to  be  evaluated  fairly  to  determine  the  benefits  of  this  technology,  the  costs 
associated  with  it,  and  its  future  growth  with  the  DoD. 

1.  The  Importance  Of  New  Technology  In  The  DoD 

Periodically,  DoD  needs  to  re-evaluate  its  mission  and  determme  the 
requirements  need  to  accomplish  its  mission.  The  DoD  also  needs  to  have  visionaries  to 
determine  how  the  mission  will  change  and  what  future  requirements  will  be  needed. 
When  performing  this  evaluation,  existing  technologies  need  to  be  examined  to 
determine  which  technology  can  support  the  requirements.  The  existing  technology 
selected  needs  to  be  able  to  migrate  into  future  technologies. 
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DoD  can’t  sit  back  and  take  a  wait-and-see  attitude  when  it  comes  to  technology. 
There  will  always  be  something  newer  and  better  just  waiting  to  be  developed.  DoD 
needs  to  be  smarter  in  determining  its  mission  and  its  requirements  to  accomplish  its 
mission. 

The  Internet  is  essential  for  many  DoD  tasks.  The  DoD  need  LANs,  P 
compatibility,  telecommuting,  P  multicast  and  bandwidth  to  be  effective  in  these  tasks. 
ISDN  needs  to  be  evaluated  to  determine  it  it  can  provide  these  requirements  for  these 
tasks. 

C.  THESIS  ORGANIZATION 

Chapter  II  identifies  related  work,  in  particular  how  ISDN  is  presently  being  used 
at  the  Naval  Postgraduate  School  (NFS)  and  in  the  private  sector.  Chapter  III  is  the 
detailed  thesis  problem  statement.  Chapter  IV  is  the  evolution  of  ISDN  and  how  the 
Regional  Bell  Operating  Companies  (RBOCs)  market  the  different  ISDN  services. 
Chapter  V  addresses  t5qjical  user  needs  relative  to  ISDN.  Chapter  VI  examines  ISDN- 
related  hardware.  Chapter  VII  is  the  experimental  results  and  Chapter  Vin  are  the 
Conclusions  and  Recommendations. 
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n.  RELATED  WORK 


A.  INTRODUCTION 

This  chapter  discusses  work  relating  to  the  larger  shared  objective  of  how  to 
connect  everyone  using  the  Internet.  Section  B  discusses  research  that  was  performed 
using  the  Multicast  Backbone  (MBone),  a  technology  that  provides  global  many-to-many 
real-time  audio/video  coimectivity  using  the  Internet.  We  believe  that  MBone 
compatibility  is  a  key  requirement  for  ISDN  use.  This  section  also  discusses  research 
occurring  at  the  Naval  Postgraduate  School  (NPS)  which  examines  different  technologies 
that  can  provide  adequate  bandwidth  to  run  MBone  tools  and  other  applications  running 
across  an  extended  LAN.  Section  C  and  D  discusses  the  current  usage  of  ISDN  at  NPS 
and  in  the  commercial  sector  respectively. 

B.  INFORMATION  INFRASTRUCTURE  RESEARCH  GROUP 

The  Information  Infrastructure  Research  Group  (IIRG)  is  a  team  of  thesis  research 
students  at  NPS.  Much  of  the  students'  research  shares  a  common  objective:  to  connect 
everyone  using  the  globally  shared  resource  of  the  Internet.  (IIRG,  96) 

The  following  are  recently  completed  NPS  theses  that  relate  to  connectivity  using 
the  MBone.  Other  related  theses  document  various  ways  to  utilize  the  MBone  tools  (as 
well  as  other  applications)  properly. 
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1.  Hamming  “Learning  to  Learn”  Multicast  Distance  Learning 

Hamming  “Learning  to  Learn  ’’  Multicast  Distance  Learning  (Emswiler,  95)  is  a 
thesis  that  addresses  how  the  MBone  and  its  tools  can  be  used  effectively  for  desktop 
conferencing  and  distance  learning.  “Effective”  in  this  context  means  the  ability  to  have 
good  audio/video  quality  across  global  Internet  connections.  This  thesis  addresses  the 
need  to  provide  an  interactive  and  cost  effective  way  to  teach  and  learn.  It  also  shows 
how  MBone  is  an  economically  feasible  approach  for  providing  widely  distributed 
audio/video  for  distance  learning. 

2.  Planning  and  Implementing  a  Wide-Area  Network  (WAN) 

Internetworking:  Planning  and  Implementing  a  Wide-Area  Network  (WAN)  for 
K-12  Schools  (Bigelow,  95)  is  a  thesis  that  documents  the  planning,  design  and 
implementation  of  a  regional  WAN  connecting  K-12  schools,  research  institutions, 
libraries  and  institutions  of  higher  education  throughout  the  Monterey  Bay  area.  The 
goal  of  the  network  is  to  enable  students  and  educators  to  have  access  to  the 
environmental  resources  available  regionally  via  the  Internet,  at  speeds  which  will 
encourage  interaction  and  maintain  interest.  The  thesis  documents  solutions 
implemented  when  connecting  this  WAN.  It  also  lists  deficiencies  preventing 
endorsement  of  ISDN  use  as  one  of  the  solutions.  Those  deficiencies  are  listed  in  Figure 
2.1. 
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Basic  Rate  Interface  (BRI)  ISDN  is  unacceptable  due  to  low  bandwidth  with 
no  compatible  upgrade  path. 

Current  high  cost  of  Primary  Rate  ISDN  is  out  of  reach  for  schools. 

Vendor  hardware  solutions  are  proprietary  and  not  interoperable.  Multilink 
PPP  may  resolve  this,  but  has  not  been  implemented. 

Figure  2.1.  Deficiencies  preventing  endorsement  of  ISDN  use.  From  (Bigelow,  95). 


3.  Global  ATM  Networks  for  Live  Multicast  AudioA^ideo 

Internetworking:  Using  Global  A  TM  Networks  for  Live  Multicast  Audio/Video 
Distribution  (Erdogan,  96)  is  a  thesis  that  documents  how  distance  learning  has  a  positive 
impact  on  the  quality  of  education  and  training  for  the  Monterey  Bay  area.  The  thesis 
shows  the  implementation  of  the  MBone  over  Monterey  BayNet  for  educational 
purposes.  The  Monterey  BayNet  is  a  regional  wide-area  network  (WAN)  which  connects 
K-12  schools,  libraries,  research  institutions  and  institutions  of  higher  education 
throughout  the  Monterey  Bay  Area.  This  thesis  shows  that  the  current  MBone 
technology  is  possible  over  a  Frame  Relay  Network.  Most  of  the  Frame  Relay  links 
tested  provide  network  connections  comparable  to  ISDN  at  128  Kbps. 

C.  ISDNATNPS 

The  biggest  advertising  pitch  for  ISDN  used  by  the  telephone  companies  has  been 
to  handle  multiple  telephone  activities.  Like  many  other  organizations’  internal 
telephone  office,  NPS  Base  Communications  is  overloaded  with  multiple  lines.  There 
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are  not  enough  analog  lines  to  handle  all  the  employees  that  need  access  to  a  phone,  fax 
or  PC.  ISDN  service  allows  NPS  Base  Communications  to  handle  these  activities  using 
multiple  telephone  numbers  from  a  single  line.  To  find  out  which  offices  use  ISDN  for 
their  office  needs  at  NPS,  contact  Jim  Baker  at  NPS  Base  Communications. 

Except  for  providing  voice  telephone  service  to  the  school,  ISDN  lines  have  only 
been  purchased  in  limited  quantities.  There  is  a  Distance  Learning  Center  (DLC)  in  Root 
Hall  which  uses  ISDN  technology  to  provide  a  room-size  video  teleconferencing  (VTC) 
system.  This  VTC  uses  transmission  speeds  greater  than  128  Kbps.  Three  Basic  Rate 
Interface  (BRI)  lines,  used  for  data,  are  “bonded”  together  to  provide  the  necessary 
bandwidth.  Point  of  contact  for  the  DLC  is  Debbie  Walsh  whose  office  is  Root  Hall, 
Room  256. 

Some  professors  in  the  Computer  Science  Department  use  data  ISDN  to 
telecommute  from  home.  Presently,  the  Computer  Science  Department  has  three  ISDN 
lines  installed  and  available  to  professors  who  have  a  need  for  this  technology. 

Curiously,  this  high-speed  capability  is  still  considered  nonessential  at  NPS.  The  demand 
by  the  user  to  deliver  adequate  bandwidth  to  maintain  an  acceptable  data  transfer  rate 
does  not  outweigh  the  cost.  Point  of  contact  for  these  three  lines  is  Rosalie  Johnson.  Her 
office  is  located  in  Spanagel  Hall,  room  527B. 

The  Systems  Technology  Lab  (STL)  has  installed  one  ISDN  line  for  the  purpose 
of  conducting  this  thesis.  They  plan  to  install  nine  more  in  the  future  and  have  the  lines 
connected  to  an  ISDN  hub.  If  this  thesis  successfully  shows  that  ISDN  supports 
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multicasting,  then  the  STL  administrators  will  use  ISDN  to  telecommute  from  home  to 
the  STL.  They  want  to  improve  security  in  the  STL  by  visually  checking  the  lab 
remotely.  Point  of  contact  is  Don  McGregor  whose  office  is  located  in  Root  Hall,  room 
205D. 

D.  ISDN  IN  THE  PRIVATE  SECTOR 

International  Data  Corporation  (IDC)  is  an  independent  consultant  firm  that 
conducted  a  survey  of  telecommunication  managers  in  1995.  The  survey  was  conducted 
to  determine  the  users  opinion  and  projection  for  a  variety  of  telecommunication  products 
and  services.  The  services  were  private-line  speeds,  data  communication  services, 
protocol  environments,  and  the  Internet.  IDC  interviewed  telecommunication  managers 
from  companies,  with  100  or  more  employees  from  within  the  seven  Regional  Bell 
Operating  Company  (RBOC)  segments.  There  were  about  218  respondents  in  all.  IDC 
analyzed  the  respondent’s  perspective  on  a  regional  basis  to  focus  on  distinctions  among 
regions.  IDC  also  analyzed  the  data  on  an  industry  basis  to  focus  on  distinctions  among 
industries.  (Shapiro/Robertson,  95) 

1.  IDC  Findings 

Migration  from  private-line  networks  is  slow.  Thirty  percent  of  the  managers 
interviewed  predict  that  their  companies  will  not  be  migrating  from  the  current  private 
networks  at  all.  However,  IDC  strongly  believes  that  although  the  migration  path  is 
slow,  the  increasingly  complex  maintenance  of  these  networks  will  drive  many 
corporations  to  reconsider  using  alternative  services  like  ISDN  and  asynchronous  transfer 
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mode  (ATM)  to  create  a  more  hybrid  approach  to  their  WAN  service  (Shapiro/Robertson, 
95). 

Appendix  A  shows  the  penetration  of  some  telecommunication  services  for  data 
traffic:  basic  exchange,  private  lines,  switched  56  Kbps,  and  ISDN.  Although  only  30% 
of  users  use  BRI  ISDN  and  16.5%  use  PRI  ISDN,  IDC  predicts  that  each  of  these 
numbers  will  increase  slowly  in  the  future  (Shapiro/Robertson,  95).  Appendix  A  shows 
the  mean  and  median  data  regarding  number  of  connections  for  each  service. 

Furthermore,  interest  in  BRI  ISDN  has  increased.  IDC  contributes  this  increase  to  the 
interest  of  remote  LAN  access  and  telecommuting.  BRI  ISDN  has  had  the  highest 
penetration  in  the  agriculture,  construction  and  mining  markets. 

E.  SUMMARY 

This  chapter  addresses  related  work  which  demonstrated  a  relationship  between 
ISDN,  the  MBone  software  tools  and  distance  learning.  Other  related  work  documents 
the  need  to  find  alternative  technology  solutions  to  successfully  utilize  the  MBone  tools 
as  well  as  other  bandwidth  intensive  applications.  This  chapter  also  addresses  how  ISDN 
is  being  deployed  at  NPS  now  and  where  some  departments  plan  to  use  it  in  the  future. 
Lastly,  it  shows  the  slow  migration  of  ISDN  in  the  private  sector. 
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m.  PROBLEM  STATEMENT 


A.  INTRODUCTION 

The  key  challenge  in  network  design  is  providing  useful  and  manageable 
connectivity  for  users.  More  and  more  organizations  are  seeing  the  need  to  tie  together 
their  islands  of  automation.  They  are  trying  to  achieve  for  data  services  what  the 
telephone  system  already  provides  for  voice  services;  the  ability  to  communicate  or  be 
connected  to  another.  Connectivity  means  allowing  users  to  communicate  up,  down, 
across,  and,  in  and  out  of  an  organization.  (Sprague  Jr/McNurlin,  93) 

This  thesis  is  about  just  that,  providing  user  connectivity  by  extending  an 
organization’s  LAN  through  the  use  of  ISDN.  Section  B  explains  the  need  for 
connectivity.  Section  C  explains  the  problems  in  achieving  connectivity.  Section  D 
discusses  video  teleconferencing  (VTC),  an  application  which  research  has  shown  aids  in 
communication.  It  also  explains  how  the  MBone  technology  can  be  used  for  VTC. 
Section  E  is  the  problem  statement  of  this  thesis;  the  need  to  evaluate  the  potential 
effectiveness  of  ISDN  for  connectivity.  Section  F  discusses  why  it  is  important  to 
evaluate  ISDN  within  the  Navy  and  Marine  Corps. 

B.  NEED  FOR  AN  EXTENDED  LAN 

There  are  many  reasons  why  organizations  are  pushing  for  connectivity  outside 
the  organization.  Figure  3.1  explains  some  of  the  major  reasons  and  is  by  no  means  an 
exhaustive  list. 
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•  Economic  constraints  have  caused  organizations  to  look  for  alternative 
solutions  to  in-person  meetings,  and,  education  and  training  requirements  that 
can  not  be  provided  locally. 

•  Geographical  dispersion  of  workers  can  create  problems  for  collaborative  work 
to  be  performed. 

•  Organizations  are  realizing  that  employees  can  be  equally  or  more  productive 
working  from  their  homes.  In  order  to  recruit  and  retain  key  personnel, 
organizations  are  providing  their  employees  with  the  ability  to  telecommute 
from  home. 

•  Transactions  between  businesses  are  increasingly  being  done  electronically. 

Figure  3.1.  Needs  for  an  extended  LAN. 

C.  CONNECTIVITY  PROBLEMS  AND  A  SOLUTION:  INTERNET 
PROTOCOL  (IP) 

The  problem  with  extending  connectivity  is  one  of  non-interoperabilities. 

Different  machines  use  different  operating  systems  with  different  hardware  interfaces  on 
different  networks.  These  machines  need  to  be  interoperable.  It  is  not  always  possible 
(and  rarely  desirable)  to  buy  end-to-end  equipment  from  the  same  vendor.  The 
connectivity  solution  needs  to  be  one  that  allows  the  exchange  of  information  in  standard 
ways  without  physical  intervention  and  without  any  changes  in  the  command  language  or 
in  functionality.  That  is  why  interoperability  must  be  stressed.  Standards  are  the 
foundation  of  the  overall  architecture  because  they  offer  the  greatest  long-term  benefits. 
Proprietary  solutions  are  to  be  reserved  for  filling  gaps  where  standards  are  not  yet 
available.  Therefore,  there  is  only  one  practical  solution  for  computer  connectivity  that 
simultaneously  addresses  all  of  these  competing  requirements:  the  Internet  Protocol  (IP). 
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D.  VIDEO  CONFERENCE  SYSTEM  NEEDED  IN  AN  EXTENDED  LAN 
Video  teleconferencing  (VTC)  is  not  a  new  technology.  Expensive  room-sized 
systems  incorporating  specialized  hardware  and  software  components  have  been  used  for 
years.  Organizations  recognize  them  as  productive  tools  and  use  them  in  distance 
learning  and  collaborative  work.  Unfortunately,  these  systems  use  proprietary  hardware 
and  software  and  do  not  interoperate  with  other  computers  due  to  incompatibility  with  IP . 

New  video  conferencing  technology  is  downsizing  these  systems  to  inexpensive 
software  that  works  on  a  PC.  Desktop  conferencing  improves  the  communication 
process  with  other  users.  It  allows  the  users  to  see  each  other.  The  subtleties  of  body 
language  and  facial  expressions  are  communicated  in  a  way  not  possible  via  fax  machine, 
e-mail  or  telephone.  As  a  result,  the  users  avoid  wasted  time  and  avert 
misunderstandings.  Additionally,  desktop  video  conferencing  systems  allow  individuals 
to  participate  in  all  functions  that  room-size  systems  allowed.  As  with  the  room-size 
VTC,  many  of  these  new  systems  use  proprietary  hardware  and  software.  There  are  some 
however  that  are  not  proprietary.  (Rettinger,  95) 

A  great  deal  of  work  in  recent  years  has  shown  that  IP-compatible  low-cost  VTC 
is  possible  globally  using  the  MBone. 

1.  MBone 

Internetworking  is  defined  as  the  ability  to  seamlessly  interconnect  multiple 
dissimilar  networks  globally  (Brutzman,  96).  Physical  connectivity  to  the  Internet  is  a 
prerequisite  to  internetworking.  In  the  past,  most  desktop  conferencing  solutions  allowed 
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only  two  people  to  participate  in  a  session.  This  precluded  using  desktop  conferencing 
for  meetings  that  required  the  connection  of  three  or  more  locations.  Today,  multipoint 
technology  makes  it  possible  for  a  group  of  people  to  see  and  hear  each  other  and 
collaborate  on  a  task  simultaneously. 

The  MBone  can  be  considered  as  a  multipoint  technology.  MBone  stands  for 
Multicast  Backbone.  It  is  a  virtual  network  layered  on  top  of  portions  of  the  physical 
Internet.  The  MBone  is  used  for  multicast  real-time  applications  such  as 
videoconferencing  and  audio. 

Many  related  theses  demonstrate  that  the  use  of  the  MBone  can  provide  a  quality 
desktop  video  conference  system.  The  MBone  applications  provide  the  necessary  tools 
for  distance  learning  and  collaborative  work.  (Erdogan,  96) 

In  the  past,  the  MBone  technology  could  only  be  transmitted  over  a  high- 
bandwidth  physical  media  (e.g.  T1  line  at  1.5  Mbps)  because  it  was  transmitting  audio 
and  video  simultaneously.  This  technology  required  a  large  bandwidth  due  to  primitive 
compression  algorithms  used  to  encode  audio  and  video  data.  Recent  developments  in 
MBone  software  applications  and  incorporation  of  sophisticated  compression  algorithms 
make  it  possible  for  this  technology  to  be  used  over  low-speed  network  connections. 

The  MBone  technology  and  associated  protocols  are  becoming  standardized  by  a 
variety  of  organizations,  most  notably  the  Internet  Engineering  Taskforce  (IETF)  Audio- 
Visual  Transport  (AVT)  working  group  (Audio/Video  Transport  Charter,  96).  A 
complete  variety  of  machines  and  operating  systems  are  already  interoperable. 
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E.  ISDN  AS  A  COMPATIBLE  SOLUTION 

New  applications  (like  the  MBone  tools)  that  require  a  moderately  large 
bandwidth  to  perform  properly  are  making  standard  telephone  technology  inadequate  for 
extending  a  LAN.  The  network  connectivity  demand  for  higher  bandwidth  is  the  driving 
factor  behind  searching  for  a  new  technology  (Wiedenhoeft,  94)  (Bigelow,  95).  The 
solution  must  not  only  be  technically  feasible  but  also  cost  effective. 

The  purpose  of  this  thesis  is  to  investigate  and  evaluate  the  potential  effectiveness 
of  using  ISDN  for  extending  a  LAN  environment.  Various  forms  of  ISDN  technology 
has  been  in  existence  for  over  ten  years.  It  remains  to  be  determined  whether  this 
technology  has  matured  sufficiently  over  the  years,  and  whether  standards  are  working 
that  will  avoid  making  ISDN  a  proprietary  solution.  A  past  thesis  made  a  preliminary 
evaluation  of  ISDN  as  a  solution  for  an  extended  LAN  and  determined  that  the  ISDN 
standards  and  technology  were  not  fully  developed  (Bigelow,  95).* 

In  1995,  Major  Michael  R.  Macedonia  USA,  a  Ph.D.  student  at  the  Naval 
Postgraduate  School  (NPS)  posted  a  question  to  the  ISDN  news  group.  He  was  trying  to 
find  out  if  anyone  had  successfully  used  MBone  over  ISDN.  At  the  time  that  Major 
Macedonia  posed  his  question,  MBone  applications  needed  more  than  128  Kbps  to 
perform  properly.  Two  BRI  “bonded”  B-channels  could  not  offer  the  required 
bandwidth.  At  that  time,  a  handful  of  users  were  using  ISDN  for  IP  and  MBone 


*Bigelow’s  findings  are  summarized  in  Chapter  II. 
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connectivity.  However,  the  usefulness  of  BRI  ISDN  for  MBone  was  problematic  due  to 
the  128  Kbps  constraint. 

The  ISDN  issues  that  Bigelow’s  thesis  identified  and  the  multicasting  problems 
that  Major  Macedonia  uncovered  need  to  be  re-evaluated.  This  thesis  investigates 
whether  show-stopper  ISDN  problems  of  the  past  are  still  present  today. 

F.  ISDN  FOR  THE  NAVY  AND  MARINE  CORPS 

Section  B  of  this  chapter  addressed  many  reasons  why  organizations  are  pushing 
for  connectivity  outside  the  organization.  These  reasons  can  apply  to  the  military  as  well. 

Not  only  is  internetworking  important  in  an  office  environment,  it  will  become 
equally  important  on  the  battlefield  for  tactical  reasons.  We  expect  that  the  battlefield 
commander  will  need  to  rely  on  internetworking  in  order  to  achieve  cooperative 
engagement  (Nierle,  96).  Previous  theses  have  shown  the  need  for  applications  to 
conform  to  IP  (Bigelow,  95)  (Nierle,  96).  IP  is  essential  to  assure  universal 
interoperability  and  hardware-independent  evolution  of  tactical  applications.  With  this  in 
mind,  information  managers  in  the  military  have  the  responsibility  to  evaluate  new 
technologies  and  find  the  one  that  bests  supports  the  needs  of  the  organization  and 
supports  IP.  One  such  candidate  technology  is  ISDN. 

G.  SUMMARY 

This  chapter  addresses  the  need  for  user  connectivity  by  extending  an 
organization’s  LAN  and  the  problems  to  achieve  it.  It  addresses  VTC  which  is  a  system 
used  in  an  extended  LAN  environment.  Many  VTCs  however  use  proprietary  hardware 
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and  software  which  create  interoperability  issues.  The  MBone  technology  and  associated 
protocols  have  been  successfully  used  in  VTC  to  achieve  interoperability.  However,  the 
MBone  application  tools  require  a  moderately  large  bandwidth  (128  Kbps)  to  perform 
properly. 

Many  technologies  are  emerging  which  are  possible  solutions  for  providing  the 
necessary  bandwidth  to  transmit  the  MBone  application  tools.  The  technology  chosen 
needs  to  provide  interoperability  standards  to  enable  extended  connectivity  and  also  be 
cost  effective.  This  chapter  addresses  the  need  to  investigate  the  current  state  of  the 
ISDN  technology  and  evaluate  the  potential  effectiveness  of  using  it  for  extending  a  LAN 
environment  within  the  military. 
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IV.  TELEPHONE  COMPANIES  ISDN  DEPLOYMENT 


A.  INTRODUCTION 

This  chapter  addresses  how  the  Regional  Bell  Operating  Companies  (RBOCs) 
deployment  of  ISDN  differs  from  RBOC  to  RBOC.  Section  B  addresses  the  evolution  of 
ISDN.  Section  C  addresses  the  International  Standards  for  ISDN.  Section  D  addresses 
the  different  services  that  each  RBOC  provides. 

B.  EVOLUTION  OF  ISDN 

Thirty  years  ago  the  entire  telephone  network  was  analog.  Information  was 
transported  through  the  network  as  an  analog  signal  from  point  to  point.  Computer 
information,  which  is  digital,  had  to  be  converted  first  to  analog  before  being  transported 
across  the  network. 

During  the  next  two  decades,  the  telecommunications  network  in  the  U.S.  went 
through  a  digital  evolution.  This  digital  evolution  began  with  the  advent  of  T-carrier,  a 
digital  interoffice  transmission  system  with  an  analog  stored  program  controlled  switch 
(Bellcore,  85).  The  T-carrier  allowed  the  phone  companies  to  stop  making  analog 
connections  between  the  central  offices  (COs).  When  a  person’s  voice  or  analog  modem 
signal  reaches  one  central  office,  it  is  promptly  digitized.  The  digital  information  is  then 
transferred  via  switches  to  the  receiving  central  office.  At  the  receiving  central  office, 
the  digital  information  is  converted  back  into  an  analog  signal  and  continues  to  its 
destination  point. 
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During  the  past  decade,  the  concept  of  digital  connectivity  has  continued.  ISDN 
is  a  technology  based  on  this  concept.  It  is  a  network  architecture  which  through 
standardization  of  user  and  network  interfaces  allows  customer  access  to  multiple 
communication  services  (Bellcore,  85).  Information  is  transported  through  the  network 
in  digital  form  from  the  customer  premises  to  its  destination  point.  The  network  is 
“integrated”  in  that  the  system  facilities  provide  end-to-end  digital  connectivity  for  voice, 
data  and  video  services.  Computers  can  connect  directly  to  the  telephone  network 
without  first  converting  their  signals  to  an  analog  audio  signal  (as  modems  do). 

The  concept  of  digital  connectivity  has  begun  to  rapidly  influence  the  trend 
towards  more  sophisticated  applications  that  require  large  bandwidths  to  perform 
properly.  The  bandwidths  that  are  required  for  these  applications  are  more  than  what  is 
allocated  to  an  analog  phone  line. 

C.  INTERNATIONAL  STANDARDS  FOR  ISDN 

The  international  telecommunications  standardization  organization  which  is  now 
known  as  the  Telecommunications  Standards  Bureau  (TSB)  has  played  a  key  role  in 
developing  standards.  The  Bureau  was  formerly  the  Consultative  Committee  for 
International  Telegraph  and  Telephone  (CCITT). 

In  1984,  two  types  of  user-network  interfaces  were  standardized  by  the  TSB  for 
ISDN:  Basic  Rate  Interface  (BRI)  and  Primary  Rate  Interface  (PRI). 
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1.  Basic  Rate  Interface  (BRl) 

The  BRI  ISDN  connection  contains  three  separate  channels:  two  B  channels  and 
one  D  channel.  Some  documentation  refers  to  these  channels  as  “pipes.”  The  two  B  (for 
bearer)  channels  transmits  the  user  information  and  are  typically  64  Kilobits  per  second 
(Kbps)  data  channels.  The  D  (for  data)  channel  carries  call-setup  and  signaling  data  (also 
known  as  out-of-band  signaling)  between  the  ISDN  device  and  the  phone  company.  It  is 
not  normally  used  for  an5dhing  else.  This  channel  is  16  Kbps.  The  two  B  channels  can 
combine  together  to  form  a  single  128  Kbps  data  channel  through  a  process  called 
“bonding.”^  The  standard  BRI  is  referred  to  as  a  2B+D  coimection.  The  BRI  ISDN 
channel  is  shown  in  Figure  4. 1 .  (Pacific  Bell,  94) 

The  signaling  information  tells  the  telephone  company  switches  what  to  do  with 
the  data  that's  being  delivered  via  the  B  channel.  This  signaling  information  opens  and 
closes  circuit  switches  to  route  calls  along  a  dedicated  path  between  caller  and  receiver. 

As  mentioned  previously,  standard  ISDN  uses  out-of-band  signaling  via  the  data  (D) 
channel.  In-band  signaling  refers  to  the  delivery  of  the  signaling  information  being  carried 
in  the  same  channel  as  the  user  information  (in  the  bearer  channel).  (Angell,  95) 

Some  local  telephone  companies  are  slow  to  implement  out-of-band  signaling 
connections  and  use  in-band  signaling.  The  in-band  signaling  uses  8  Kbps  in  the  B  channel 
causing  the  B  channel  to  only  transmit  data  at  56  Kbps  instead  of  the  standard  64  Kbps. 

^Protocols  for  achieving  128  Kbps  transmission  are  addressed  further  in  Chapter 
V. 
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Pacific  Bell  (PacBell)  does  not  offer  out-of-band  signaling  in  the  Monterey  area  (although 
their  ISDN  sales  representatives  say  they  do). 


Figure  4. 1 .  Basic  Rate  Interface  (BRI)  ISDN  channels.  From  (Pacific  Bell,  94). 


2.  Primary  Rate  Interface  (PRI) 

Primary  Rate  Interface  OPRI)  consists  of 23  64  Kbps  B  channels  and  one  64  Kbps 
D  channel.  It  is  referred  to  as  23B  +  D.  One  PRI  line  is  much  cheaper  than  eleven  and  a 
half  BRI  lines.  If  users  need  a  large  number  of  ISDN  lines  in  one  place  or  need  a  line  that 
can  transmit  more  than  128  Kbps,  PRI  should  be  used.  Using  one  PRI  line  or  multiple 
BRI  lines  is  more  cost  effective  than  using  a  standard  T1  line. 

D.  REGIONAL  BELL  OPERATING  COMPANIES  (RBOC)  ISDN 

DEPLOYMENT 

Dedicated  digital  telephone  lines  have  been  around  for  a  long  time.  They  are 
leased  lines  that  operate  24  hours  each  day  for  a  fixed  monthly  rate.  There  are  no 
connection-by-connection  usage  charges  associated  with  dedicated  lines.  ISDN  is  not 
considered  a  dedicated  system. 

ISDN  is  an  on-demand  system  and  is  treated  in  many  ways  like  plain  old  telephone 
service  (POTS)  in  terms  of  charges.  If  a  person  makes  a  local  call,  the  local  telephone 
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company  charges  the  person  for  that  call.  If  a  person  makes  a  long-distance  call,  the  long¬ 
distance  telephone  company  charges  for  the  call.  ISDN  billing  works  similarly.  Therefore 
it  is  impractical  to  use  an  ISDN  line  as  a  dedicated  connection  24  hours  a  day  since  billing 
tariffs  are  not  economical. 

In  1992,  the  Regional  Bell  Operating  Companies  (RBOCs)  and  network  switching 
system  manufactures  made  an  agreement  to  provide  standard  ISDN  services.  This 
commitment  is  called  National  ISDN.  National  ISDN  specifies  the  way  that  telephones 
and  computers  communicate  with  the  ISDN  network.  The  National  ISDN  agreement 
ensures  that  each  central  office  switch  operates  in  a  standard  way,  providing  a  uniform 
interface  to  the  Customer  Premises  Equipment  (CPE).  (U.  S.  West,  96) 

In  recent  years  the  United  States  has  had  seven  RBOCs.^  Each  company  provides 
telephone  services  for  that  region.  In  addition  to  the  RBOCs,  there  are  independent 
telephone  companies  (ITCs).  All  of  these  companies  provide  local  service.  Long  distance 
telephone  companies  are  called  InterExchange  Carriers  (IC  or  lEC).  They  provide  service 
between  local  telephone  companies.  With  the  Telecommunications  Deregulation  Act  of 
1996,  the  lECs  can  now  compete  in  the  local  market  as  well  (S.652,  96).  These 
companies  operate  independently  which  results  in  uneven  ISDN  service  availability, 
pricing  and  service.  Sometimes  it  is  difficult  to  get  reliable,  consistent  answers  fi'om  these 
providers  about  their  ISDN  services. 

Pacific  Bell  is  merging  with  South  Western  Bell  and  Bell  Atlantic  is  merging  with 
NYNEX.  When  this  happens,  there  will  be  five  RBOCs  instead  of  seven. 
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Some  telephone  companies  are  trying  to  make  ISDN  easy  to  use.  They  are 
constantly  updating  their  office  equipment  to  comply  with  TSB  standards.  These 
companies  are  using  aggressive  marketing  strategies  to  sell  ISDN  as  the  latest  and  greatest 
in  modem  technology.  Other  telephone  companies  continue  to  be  sluggish  in  ISDN 
implementation.  They  are  waiting  for  the  market  to  come  to  them.  However,  the 
demand  for  ISDN  in  these  areas  will  never  increase  if  the  ISDN  equipment  manufacturers 
and  local  telephone  company  do  not  collaborate  and  market  the  product.  (Angell,  96) 

1.  Different  ISDN  Services 

Although  the  BRI  standard  is  2B+D,  different  telephone  companies  offer  a  variety 
of  BRI  channel  configurations.  The  BRI  channel  configuration  determines  the  type  of 
information  that  gets  transmitted  through  each  B  channel.  Therefore  it  is  important  for  the 
user  to  know  beforehand  what  the  requirements  for  the  ISDN  line  are  before  ordering  the 
service.  If  user  needs  requirements  change,  the  channel  configuration  may  change  (and 
the  phone  company  will  charge  for  the  change).  Figure  4.2  lists  the  available  BRI  channel 
configuration  options; 
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Interface  Type 

Interface  Configuration 

OB+D 

D  Channel  Only 

IB 

IB  Voice 

IB 

IB  Data 

IB 

IB  Alternate  Voice/Data 

IB 

IB  Packet  Data 

IB+D 

IB  Voice,  D  Packet  Data 

IB+D 

IB  Data,  D  Packet  Data 

IB+D 

IB  Alternate  Voice/Data,  D  Packet  Data 

2B 

IB  Voice,  IB  Data 

2B 

IB  Voice,  IB  Packet 

2B 

2B  Data 

2B 

IB  Data,  IB  Voice/Data 

2B 

IB  Data,  IB  Packet  Data 

2B 

IB  Voice/Data,  IB  Packet  Data 

2B+D 

IB  Voice,  IB  Packet  Data 

2B+D 

2B  Data,  D  Packet  Data 

2B+D 

IB  Data,  IB  Voice/Data,  D  Packet  Data 

Figure  4.2.  BRI  channel  configuration  options.  From  (Angell,  95). 


Most  ISDN  equipment  is  flexible  enough  to  operate  on  any  ISDN  line.  The  local 
telephone  company  has  special  ISDN  ordering  operators  so  they  can  assist  the  user  in 
determining  which  service  is  appropriate. 
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2.  Different  Telephone  Company  Switching  Systems 

A  switch  refers  to  electronic  facilities  that  route  telephone  traffic  from  one 
destination  to  another.  ISDN  service  is  a  circuit  switching  system.  The  term  circuit 
switching  means  that  the  communications  pathway  remains  fixed  for  the  duration  of  the 
call  and  is  unavailable  to  other  users.  Electronic  switching  software  operated  on  specialize 
switching  computers  provides  the  basis  for  the  operation  of  ISDN. 

(AngeU,  95) 

By  way  of  contrast,  the  term  packet  switching  refers  to  the  sending  of  data  in 
packets  that  are  individually  sent  by  the  most  efficient  route  and  then  reassembled  at  their 
destination.  IP  packets  sent  by  a  single  users  computers  pass  through  the  point-to-point 
ISDN  connection  and  are  then  connected  to  a  LAN,  where  they  can  be  routed  an5nvhere 
on  the  Internet. 

The  leading  digital  circuit  switches  used  by  RBOC  are  AT&T’s  5ESS  (Electronic 
Switching  System)  and  Northern  Telecom’s  (NT)  DMS-100  switches.  The  5ESS  uses 
either  Custom  or  National  ISDN  1  (NI-l)  software  and  the  DMS-100  uses  only  NI-1 
software.  (Angell,  95) 

These  switches  (and  their  associated  software)  have  become  standard  because 
compatibility  between  user  ISDN  equipment  and  the  telephone  company’s  switch  is 
necessary  to  communicate  via  ISDN.  Therefore,  when  ordering  ISDN  service,  the  user 
needs  to  tell  the  telephone  company  the  exact  brand  and  model  of  the  equipment  that  will 
be  used  on  the  ISDN  line. 
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3.  Inconsistent  ISDN  Pricing 

ISDN  pricing  policies  are  called  tariffs  by  the  phone  companies.  The  tariff  is  based 
on  complex  cost  allocations  and  recovery  rules  established  by  federal  and  state  regulators.^ 
Therefore,  ISDN  pricing  varies  from  one  RBOC  to  another  and  from  state  to  state.  For 
example,  the  California  Public  Utilities  Commission  (CPUC)  recently  changed  its  order 
and  related  pricing  rules  on  March  13,  1996  (Pacific  Bell,  96).  This  provided  new 
guidelines  for  PacBell  to  resell  its  products  and  services. 

The  CPUC’s  order  moved  ISDN  into  a  competitive  product  category.  This  means 
that  the  product  is  divided  into  separate  components  (e.g.  usage,  monthly  fee  and 
installation).  Each  cost  component  is  priced  separately  to  enable  the  company  to  recover 
its  expenses  in  accordance  with  regulatory  rules.  As  a  result,  the  various  cost  components 
may  no  longer  subsidize  each  other.  (Pacific  Bell,  96) 

As  a  result  of  this  order,  PacBell  filed  its  new  tariff  with  the  CPUC.  It  proposed 
raising  the  monthly  fee  by  $8.  The  increase  was  filed  because  PacBell  originally  expected 
only  12  percent  of  its  ISDN  customers  to  require  repeaters.  It  has  found  that  24  percent 
of  business  ISDN  users  and  30  percent  of  personal  ISDN  users  are  located  more  than  3 
miles  from  the  central  office.  PacBell  was  not  charging  extra  for  repeaters.  The  cost  to 
provision  and  maintain  high-quality,  high-speed  digital  lines  in  rural  areas  is  higher  than  in 
metropolitan  areas.  PacBell’s  analyses  showed  that  their  current  prices  would  not  sustain 
their  ISDN  service  offerings.  (Pacific  Bell,  96) 

^Tariffs  are  not  based  on  competition. 
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The  total  cost  to  receive  ISDN  services  is  dependent  upon  the  configuration  option 
chosen  above,  installation  costs,  distance  charges,  usage  charges  and  a  fixed  monthly  fee. 
Continued  variation  in  pricing  can  be  expected  to  continue  as  the  telecommunications 
industry  is  deregulated,  services  improve  and  competition  increases.  Further  reduction  in 
costs  for  educational  connectivity  is  likely  in  this  rapidly  changing  environment.  Appendix 
B  shows  the  current  tariffs  and  installation  costs  for  each  of  the  RBOCs. 

4.  Joint  Marketing/Alliance  Agreements  with  the  Local  Exchange 
Carrier  (LEC) 

In  order  to  market  ISDN  better,  the  telephone  companies  and  ISDN  equipment 
vendors  have  been  working  together  to  make  setting  up  a  connection  easier.  Each  Local 
Exchange  Carrier  (LEC)  has  been  forming  alliances  with  CPE  vendors  that  allow  both 
parties  to  jointly  sell  their  products.  The  joint  selling  approach  focuses  on  delivery  of  a 
complete  solution  for  a  customer’s  application.  Under  this  type  of  program,  ISDN 
services  can  be  standardized  for  that  RBOC  area.  With  standardization,  vendors  can 
ensure  interoperability  of  equipment. 

Several  RBOCs  have  facilities  for  testing  ISDN  CPE  and  applications.  The 
testing  is  divided  into  three  categories:  ISDN  Protocol  Compatibility  Testing, 
Interoperability  Testing  and  ISDN  CPE  “SUPER”  Testing.  “SUPER”  testing  includes 
human  factors  testing  (Bellcore,  96).  The  phone  companies  have  a  list  of  approved  ISDN 
vendors  and  products  that  work  with  that  LEC’s  switches. 
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E.  SUMMARY 


This  chapter  addresses  the  evolution  of  ISDN  and  the  ISDN  International 
Standards.  It  also  addresses  how  the  Regional  Bell  Operating  Companies  (RBOCs) 
deployment  of  ISDN  differs  from  RBOC  to  RBOC. 
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V.  USER  NEEDS  ANALYSIS  RELATIVE  TO  ISDN 


A.  INTRODUCTION 

This  chapter  gives  an  analysis  of  user  needs  for  an  extended  LAN  relative  to 
ISDN  capabilities.  Section  B  deals  with  the  applications  used  in  an  extended  LAN.  In 
order  to  have  these  applications,  the  user  needs  a  technology  that  will  support  these 
applications.  User  applications  provide  the  driving  requirements. 

Sections  C  through  E  describe  what  functions  ISDN  needs  to  support. 

Specifically,  section  C  explains  the  Transmission  Control  Protocol/  Internet  Protocol 
(TCP/IP)  standards  and  the  Open  Systems  Interconnection  (OSI)  reference  model.  The 
ISDN  reference  model  is  mapped  to  OSI  and  TCP/IP  to  explain  how  it  is  technically 
possible  to  interconnect  two  systems  using  ISDN. 

Section  D  explains  the  different  functions  of  ISDN  that  cannot  be  directly  mapped 
to  layers  in  these  well-known  reference  models.  The  different  ISDN  functions  are 
needed  to  provide  a  standard  to  achieve  interoperability  between  two  systems  and  to 
explain  how  the  technology  can  provide  the  necessary  bandwidth  to  run  the  user’s 
software  applications. 

Section  E  describes  multicasting  which  is  an  inherent  requirement  for  an  extended 
LAN  environment.  MBone  technology  is  an  example  of  a  network  that  requires 
multicasting.  The  MBone  application  tools  are  selected  to  test  whether  ISDN  supports 
multicasting. 
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Section  F  gives  an  economic  analysis  of  how  much  it  will  cost  a  command  to 
extend  their  LAN  connectivity  using  ISDN. 

B.  SOFTWARE  APPLICATIONS 

The  typical  oflBce  connection  with  analog  lines  looks  like  Figure  5.1:  a  telephone 
for  voice,  a  fax  device  to  send  documents,  and  a  telephone  modem  to  connect  remotely  to 
a  LAN  or  to  the  Internet.  If  users  have  only  one  Plain  Old  Telephone  Service  (POTS) 
line,  they  can  only  make  one  of  these  connections  at  a  time.  Ordinarily,  to  conduct 
multiple  tasks  at  the  same  time,  you  must  have  a  separate  analog  line  for  each  device. 

ISDN  can  allow  multiple  dissimilar  connections  simultaneously.  The  digital 
connection  of  ISDN  can  deliver  up  to  three  separate  calls  at  one  time  (given  the 
appropriate  ISDN-capable  telephone  devices  and  line  configuration).  An  analog  line 
delivers  one  call  at  a  time.  Figure  5.1  compares  an  oflBce  setup  using  either  one  analog 
line  or  an  ISDN  setup. 


Figure  5.1.  Analog  vs.  ISDN.  From  (Pacific  Bell,  94). 
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The  combined  voice  and  data  capabilities  of  ISDN  can  support  a  broad  range  of 
applications.  However,  unlike  traditional  POTS  phone  lines  which  all  work  alike,  ISDN 
lines  must  be  configured  to  the  user’s  applications.  For  example,  the  setup  and 
equipment  for  a  LAN-extension  environment  is  different  from  the  setup  and  equipment  of 
a  room-sized  video  teleconference  (VTC)  application,  or  an  environment  where  the  user 
is  carrying  on  simultaneous  voice  and  data  traffic.  This  thesis  only  covers  IP-based 
applications  which  extends  the  user’s  LAN  environment.^ 

1.  Telecommuting 

Telecommuters  are  employees  who  work  from  home  part  or  full  time.  The  idea 
of  telecommuting  using  ISDN  is  to  transport  most  of  the  functionality  of  the  office  to  the 
home.  Typical  office  functions  pertinent  to  the  use  of  ISDN  are  included  in  Figure  5.2. 

•  High-speed  access  to  the  user’s  LAN  and  file  servers. 

•  Fast  interconnections  to  other  company  LANs  or  hosts,  remote  systems. 

•  Interconnections  to  other  networks  especially  the  Internet. 

•  Access  to  and  the  ability  to  use  electronic  mail  (e-mail). 

•  Teleconferenced  meetings  using  Multicast  Backbone  (MBone)  applications. 

Figure  5.2.  OflBce  functionality  needs  for  telecommuting. 


*The  ISDN  line  used  for  this  extended  LAN  is  a  2B+D  line  for  data  only. 
Different  line  configurations  are  explained  in  Chapter  IV. 
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In  order  to  achieve  this  extended  LAN,  the  user  needs  a  technology  that  can 
support  more  bandwidth  than  a  28.8  Kbps  modem  provides.  Bandwidth  means  data 
transmission  capacity.  The  greater  the  bandwidth,  the  more  data  can  pass  through  the 
media  in  a  given  amount  of  time.  Many  new  applications  require  a  lot  of  bandwidth  to 
maintain  a  data  transfer  rate  acceptable  to  the  user.  The  demand  for  this  bandwidth  by 
applications  is  the  driving  force  in  finding  alternative  technological  solutions  to  analog 
telephone  lines.  (Wiedenhoeft,  94) 

A  POTS  line  can  support  a  28.8  Kbps  modem  which  can  provide  certain  office 
functions  adequately  (e.g.  e-mail,  file  transfer,  slow  Internet  access).  However,  as 
graphical  user  interfaces  in  Web  browsers  (e.g.  Netscape)  become  the  standard  interface 
on  the  Internet,  users  demand  higher-speed  connectivity  to  the  Internet.  It  is  not  practical 
to  use  28.8  Kbps  modems  to  retrieve  large  graphics,  audio  or  video  files  over  the  Internet 
because  the  modem  speeds  are  slow.  The  user  will  find  that  it  will  take  a  long  time  to 
upload  applications  or  download  information.  Exceptionally  long  transfers  also  run  the 
risk  of  losing  the  entire  transfer  if  connection  reliability  is  poor.  Since  personnel  costs 
and  productivity  are  paramount,  it  is  easy  to  understand  why  proper  network  support  is 
crucial. 

Desktop  VTC  is  another  example  of  a  multimedia  application  that  is  needed  in  an 
extended  LAN  environment  and  requires  a  lot  of  bandwidth.^  VTC  depends  on  the 
ability  to  communicate  fi'om  one-to-many  or  many-to-many  hosts.  Current  studies  show 

^  VTC  is  addressed  as  a  need  for  an  extended  LAN  in  Chapter  III. 


34 


that  the  MBone  can  provide  an  economically  feasible  desktop  VTC  system  (Erdogan,  96) 
(Rettinger,  95)  (Tiddy,  96).  With  sophisticated  compression  control  algorithms,  the  new 
MBone  tools  can  run  effectively  over  a  128  Kbps  bandwidth.  MBone  also  requires 
standard  IP  connectivity  to  support  multicasting.  This  thesis  tests  if  it  is  technically 
feasible  to  use  ISDN  technology  to  support  a  desktop  VTC  system.  Multicasting  and 
MBone  application  tools  are  explained  further  in  section  E. 

C.  ISDN  REFERENCE  MODEL 

Both  TCP/IP  and  OSI  explain  how  computers  of  all  sizes,  from  many  different 
computer  vendors  running  totally  different  operating  systems,  can  effectively 
communicate  with  each  other.  No  matter  how  different,  two  systems  can  communicate 
effectively  if  they  have  the  following  attributes  in  common  (Figure  5.3): 

•  Functions:  they  implement  the  same  set  of  communications  functions. 

•  Organization:  these  functions  are  organized  into  the  same  set  of  layers.  Peer 
layers  must  provide  the  same  functions,  but  note  that  it  is  not  necessary  that 
they  provide  them  in  the  same  way. 

•  Protocol:  peer  layers  must  share  a  common  protocol. 

Figure  5.3,  Common  attributes  for  communicating  systems.  From  (Stallings,  88). 

Each  model  is  based  on  functional  layers  to  define  the  communication  capabilities 
needed  to  enable  any  two  machines  to  communicate  with  each  other.  A  protocol  is  a  set 
of  conventions  to  describe  the  rules  of  communications  between  entities  in  a 
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communications  environment.  Communication  is  achieved  by  having  corresponding 
entities  in  the  same  layer  in  two  different  systems  communicate  through  protocols. 

The  OSI  is  the  most  widely  discussed  network  reference  model  but  is  of  little 
practical  interest  since  it  is  not  widely  implemented.  The  TCP/IP  protocol  suite,  on  the 
other  hand,  is  widely  implemented  because  of  the  ubiquitous  nature  of  the  Internet. 
Although  ISDN  does  not  directly  depend  on  TCP/IP  or  OSI,  the  two  models  can  be  used 
to  map  out  and  illustrate  ISDN’s  protocol  architecture  to  explain  how  to  connect  ISDN 
devices  and  higher-layer  services.  The  TCP/IP  and  OSI  models  are  presented  first  so  that 
they  can  be  compared  with  ISDN’s  protocol  architecture. 

1.  TCP/IP 

Networking  protocols  are  normally  developed  in  layers,  with  each  layer 
responsible  for  a  different  facet  of  the  communications.  This  division  of  labor  is  to 
provide  clarity  and  interoperability  among  software  components.  TCP/IP  is  certainly  the 
most  widely  implemented  set  of  protocols  because  of  the  Internet.  It  is  normally 
considered  to  be  a  4-layer  system  as  shown  in  Figure  5.4.  This  protocol  suite  defines  and 
routes  datagrams  across  the  Internet  and  provides  connectionless  transport  service.  The 
TCP/IP  protocol  uses  packet  switching  (i.e.  routing).  TCP  provides  reliable  deliveiy, 
while  UDP  provides  a  best  effort  (i.e.  unreliable)  service  to  deliver  its  packets. 
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APPLICATION 

TELTSIET,  FTP,  E-MAIL 

TRANSPORT 

TCP,  UDP 

NETWORK 

IP,ICMP,IGMP 

— - - 

LINK 

Device  driver  and  interface  card 

Figure  5.4.  Four  layers  of  the  TCP/IP  protocol  suite  with  example  components. 
From  (Stevens,  94). 


a.  Link  Layer 

The  IP  protocol  uses  the  services  of  the  link  layer  to  accomplish  the  actual 
transmission  along  the  path.  This  layer  is  sometimes  called  the  data-link  or  the  network 
interface  layer  and  normally  includes  the  device  driver  in  the  operating  system  and  the 
corresponding  network  interface  card  in  the  computer.  Together  they  handle  the 
hardware  details  of  physically  interfacing  with  the  cable  or  whatever  type  of  media  is 
being  used. 

b.  Network  Layer 

The  network  layer  (sometimes  called  the  Internet  layer)  handles  the 
movement  of  packets  around  the  network.  Data  packets  are  encapsulated  with  an  IP 
datagram  which  contains  routing  information.  This  layer  is  responsible  for  receiving  or 
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ignoring  incoming  datagrams  as  appropriate  from  other  hosts.  It  also  handles  network 
error  and  control  messages.  Internet  Protocol  (IP),  Internet  Control  Message  Protocol 
(ICMP)  and  Internet  Group  Management  Protocol  (IGMP)  are  the  protocols  that  operate 
at  this  layer. 

c.  Transport  Layer 

The  transport  layer  provides  a  flow  of  data  between  two  hosts,  for  the 
application  layer  above.  In  the  standardized  TCP/IP  model  there  are  currently  two 
different  standardized  transport  protocols:  Transmission  Control  Protocol  (TCP)  and 
User  Datagram  Protocol  (UDP). 

TCP  provides  a  reliable  flow  of  data  between  exactly  two  hosts.  It  is  concerned 
with  tasks  such  as  dividing  the  data  passed  to  it  from  the  application  into  appropriately 
sized  packets  for  the  network  layer  below,  acknowledging  received  packets,  and  setting 
timeouts  to  make  certain  the  other  end  acknowledges  packets  that  are  sent.  It  is  also 
responsible  for  reordering  datagrams  that  arrive  out  of  order.  Although  individual 
packets  are  not  constrained  to  follow  identical  routes,  TCP  is  referred  to  as  a 
“connection-oriented”  protocol  since  transport  layers  on  corresponding  end  hosts  see  a 
single  reliable  connection  between  them. 

UDP  sends  packets  of  data  called  datagrams  from  one  host  to  the  other,  but  there 
is  no  guarantee  that  the  datagrams  reach  the  other  end.  Any  desired  reliability  must  be 
added  by  the  application  layer.  Thus  UDP  communications  are  often  called 
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“connectionless”  because  their  is  no  logical  requirement  for  acknowledgment  or 
retransmission  when  losses  occur. 

d.  Application  Layer 

This  layer  handles  the  details  of  the  particular  application,  which  is 
usually  a  software  process.  There  are  many  common  TCP/CP  applications  that  almost 
every  IP-compatible  operating  system  provides.  Several  are  listed  Figure  5.5. 

•  telnet  for  remote  login 

•  File  Transfer  Protocol  (ftp) 

•  Simple  Mail  Transfer  Protocol  (SMTP),  for  electronic  mail 

•  Simple  Network  Management  Protocol  (SNMP) 

Figure  5.5.  Example  TCP/IP  applications.  From  (Stevens,  94). 

2.  OSI  Model 

The  OSI  model  is  a  widely  referenced  network  software  structuring  technique 
also  based  on  vertical  layers.  It  was  developed  by  the  International  Standardization 
Organization  (ISO).  Like  the  IP  protocols,  it  provides  a  framework  for  defining  a  set  of 
standards  to  describe  how  the  communication  of  computers  works.  However  it  is  not 
widely  implemented  in  practice. 

Each  OSI  layer  performs  a  related  subset  of  the  functions  required  to 
communicate  with  another  system.  It  relies  on  the  adjacent  lower  layer  to  perform  more 
primitive  functions  and  to  conceal  the  details  of  those  functions.  Each  layer  also 


39 


provides  services  to  the  adjacent  higher  layer.  The  functions  and  capabilities  expected  at 
each  layer  are  specified  in  the  reference  model.  The  model  does  not  specify  however, 
how  this  functionality  must  be  implemented.  The  requirement  to  interface  to  adjacent 
layers  t5Apically  provides  undesirable  overhead  since  direct  communication  between 
nonadjacent  layers  is  not  permitted.  For  clarity,  a  representation  of  the  OSI  model 
mapped  to  corresponding  layers  in  the  TCP/IP  model  is  shown  in  Figure  5.6. 
Explanations  of  each  layer  follow. 


OSI  TCP/IP 


APPLICATION 

APPLICATION 

PRESENTATION 

SESSION 

TRANSPORT 

TRANSPORT 

NETWORK 

NETWORK 

DATA  LINK 

LINK 

PHYSICAL 

Figure  5.6.  Correspondence  between  OSI  and  TCP/IP  models.  From  (Brutzman,96). 
a.  OSI  Application  Layer 

The  application  layer  is  responsible  for  giving  user  applications  access  to 
the  network.  Examples  of  application-layer  tasks  include  file  transfer,  electronic-mail 
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services,  and  network  management.  To  accomplish  its  tasks,  the  OSI  application  layer 
passes  program  requests  and  data  to  the  OSI  presentation  layer,  which  is  responsible  for 
encoding  the  application  layer’s  data  in  the  appropriate  form. 

b.  OSI  Presentation  Layer 

The  OSI  presentation  layer  is  responsible  for  presenting  information  in  a 
manner  suitable  for  the  applications  or  users  dealing  with  the  information.  Functions 
such  as  data  conversion,  special  graphics  or  character  sets,  data  compression  or 
expansion  are  carried  out  at  this  layer. 

c.  OSI  Session  Layer 

The  OSI  session  layer  is  responsible  for  synchronizing  and  sequencing  the 
dialog  and  packets  in  a  network  connection.  This  layer  is  also  responsible  for  making 
sure  that  the  connection  is  maintained  until  the  transmission  is  complete,  and  ensuring 
that  appropriate  security  measures  are  taken  during  the  connection.  Functions  defined  at 
the  session  layer  include  those  for  network  gateway  communications. 

d  OSI  Transport  Layer 

This  layer  is  crucial  because  it  sits  between  the  upper  layers  (which  are 
application  dependent)  and  the  lower  ones  (which  are  network  based).  This  layer  is 
responsible  for  providing  data  transfer  at  an  agreed-upon  level  of  quality,  such  as  transfer 
at  specified  transmission  speeds  and  error  rates.  To  ensure  delivery,  outgoing  packets  are 
assigned  numbers  in  sequence.  The  sequence  numbers  are  included  in  the  packets  that 
are  transmitted  by  lower  layers.  The  corresponding  transport  layer  at  the  receiving  end 
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checks  the  packet  numbers  (to  make  sure  all  have  been  delivered)  and  to  put  the  packet 
contents  into  the  proper  sequence  for  the  recipient.  Finally,  the  transport  layer  provides 
services  for  the  session  layer  above  and  uses  the  network  layer  below  it  to  find  a  route 
between  source  and  destination. 

e  OSI  Network  Layer 

The  OSI  network  layer  is  also  known  as  the  packet  layer.  It  is  responsible 
for  determining  addresses  or  translating  from  hardware  to  network  addresses.  These 
addresses  may  be  on  a  local  network,  or  they  may  refer  to  networks  located  elsewhere  on 
an  internetwork. 

One  of  the  functions  of  the  OSI  network  layer  is  to  provide  capabilities  needed  to 
communicate  on  an  internetwork.  The  layer  is  also  responsible  for  finding  a  route 
between  a  source  and  a  destination  node  or  between  two  intermediate  devices.  It  is 
responsible  for  establishing  and  maintaining  a  logical  connection  between  these  two 
nodes  to  establish  either  a  logically  coimectionless  or  a  logically  connection-oriented 
communication. 

Data  is  processed  and  transmitted  using  the  data-link  layer  below  the  network 
layer.  Responsibility  for  guaranteeing  proper  delivery  of  the  packets  lies  with  the  OSI 
transport  layer,  which  uses  network-layer  services. 
f.  OSI  Data  Link  Layer 

This  layer  reproduces,  transmits  and  receives  data  packets.  The  layer 
provides  services  for  the  various  protocols  at  the  network  layer,  and  uses  the  physical 


layer  to  transmit  or  receive  material.  The  OSI  data  link  layer  creates  packets  appropriate 
for  the  network  architecture  being  used.  Requests  and  data  from  the  network  layer  are 
part  of  the  data  in  these  packets.  These  packets  are  passed  down  to  the  OSI  physical 
layer. 

g.  OSI  Physical  Layer 

The  OSI  physical  layer  is  the  lowest  layer  in  the  model.  This  layer  gets 
data  packets  from  the  OSI  data  link  layer  and  converts  the  contents  of  these  packets  into  a 
series  of  electrical  signals  that  represent  0  and  1  values  in  a  digital  transmission.  These 
signals  are  sent  across  a  transmission  medium  to  the  OSI  physical  layer  at  the  receiving 
end.  At  the  destination,  the  corresponding  OSI  physical  layer  converts  the  electrical 
signals  into  a  series  of  bit  values.  These  values  are  grouped  into  packets  and  passed  up  to 
the  local  OSI  data  link  layer. 

3,  ISDN  MODEL 

ISDN  is  used  for  user-to-user  communications  and  for  user-to-network 
communications.  The  bulk  of  ISDN  protocols  deal  with  the  interface  between  the  user 
site  and  the  network  over  the  D-channel.  The  protocols  dealing  with  the  B-channel  are 
basically  transparent  to  the  ISDN  user  applications. 

The  TCP/IP  protocols  primarily  deal  with  network  interactions  above  the  data 
link  layer.  This  means  that  IP  can  typically  be  sent  using  any  data  link  and  physical  link 
protocols.  The  ISDN  model  can  be  mapped  to  the  bottom  two  layers  of  the  TCP/IP  stack 
(i.e.  the  Link  Layer  and  Network  Layer).  ISDN  is  essentially  unconcerned  with  the 
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Transport  and  Application  layers  of  TCP/IP  because  ISDN  deals  solely  with  end-point 
network  access  and  not  with  end-to-end  routing  of  Internet  traffic  between  hosts.  The 
Transport  and  Application  Layers  deal  with  connection  management  and  end-to-end  host 
connectivity.  Applications  on  the  host  machines  communicating  over  the  network  are 
expected  to  provide  their  own  end-to-end  services.  Otherwise  they  rely  on  TCP/IP 
transport  protocols  (UDP/TCP)  to  provide  such  services.  (Tittel/James,  96) 

The  manner  in  which  IP  is  transferred  over  ISDN  is  specified  in  (RFC  1356).  The 
Experimental  Results  chapter  in  this  thesis  tests  whether  IP  (in  particular  multicast  IP ) 
can  run  over  the  data  and  physical  link  of  BRI  ISDN. 

Figure  5.7  shows  this  comparison  between  OSI,  TCP/IP  and  ISDN  models. 
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Figure  5.7.  Correlation  between  OSI,  TCP/IP  and  ISDN  models. 
After  (Tittel/James,  96). 
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Switching  1  Circuit  |  Switching 


a,  ISDN  Layer  1 

Figure  5.8  lists  the  functions  of  ISDN  layer  1. 

•  Encoding  of  digital  data 

•  Duplex  transmission  over  the  B-channel 

•  Duplex  transmission  over  the  D-channel 

•  Multiplexing  of  BRI  or  PRI  connections 

•  Activation  and  deactivation  of  the  virtual  circuit 

•  Provision  of  power  from  NTl  to  terminal 

•  Faulty  terminal  isolation 

•  D-channel  contention/access 

Figure  5.8.  ISDN  Layer  1  functions.  From  (Tittel/James,  96). 

ISDN  Layer  1  describes  the  physical  connections  between  ISDN  devices  and  the 
network  termination  device  (NTl).  CCITT  Recommendation  1.430  defines  the  physical 
layer  specifications  for  the  BRI  channel.  The  PRI  physical  layer  is  defined  in  CCITT 
Recommendation  1.43 1 . 

b.  ISDN  Layer  2 


This  layer  is  concerned  with  the  communications  between  two  machines. 
With  ISDN  the  responsibility  for  call  setup,  maintenance  and  disconnection  between  two 
machines  lies  with  the  D-channel.  For  this  reason,  Link  Access  Procedures  (LAP-D)  is 


concerned  mainly  with  the  D-channel.  LAP-D  is  defined  in  CCITT  standards  1.440  and 
1.441. 

LAP-D’s  purpose  is  to  provide  two  types  of  service.  It  must  handle  multiple 
terminals  on  the  user-network  side  of  the  NTl,  and  it  must  be  able  to  support 
communication  between  multiple  layer  3  protocols  operating  on  the  ISDN. 

Link  Access  Protocol-B  (LAP-B)  is  the  X.25  layer  two  protocol.  CCITT 
standards  specify  that  X.25  may  be  used  for  packet-switching  transmission  on  the  D- 
channel.  X.25  was  in  existence  before  ISDN  standards  and  so  LAP-B  incorporated  X.25 
in  its  standard.  However  there  are  problems  using  LAP-B  over  the  D-channel  and  many 
authors  recommend  avoiding  use  of  LAP-B  in  an  ISDN  network  (Angell,  1996). 
Essentially  this  is  a  hardware  design  issue  of  little  direct  interest  to  ISDN  users. 
c.  ISDN  Layer  3 

ISDN  Layer  3  is  concerned  with  network  functions  of  addressing,  routing 
and  delivery  of  information.  On  an  ISDN  network,  the  D-channel  is  designated  to 
perform  these  functions.  This  layer  deals  with  signaling  procedures  established  between 
the  user  network  and  the  ISDN,  call  control,  and  access  to  and  control  of  supplementary 
services.^  This  protocol  information  is  carried  across  the  network  in  LAP-D  frames. 
(Tittel/James,  95) 


^Internal  network  signaling  is  carried  out  by  out-of-band  signaling  which  is 
discussed  in  Chapter  IV.  Layer  3  signaling  discussed  here  deals  with  signals  carried 
from  the  user  network  or  terminal  to  the  ISDN. 
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CCITT  standard  1.451  describes  call  control  procedures.  X.25  is  a  protocol  suite 
that  defines  operations  between  devices  in  a  packet-switching  network.  X.25  was  in 
existence  before  ISDN,  and  ISDN  has  incorporated  the  X.25  standards  when  dealing  with 
a  packet-switching  network.  Otherwise  the  ISDN  network  mainly  concerns  itself  with 
channel  D. 

D.  ISDN  FUNCTIONS  NOT  DIRECTLY  MAPPED  TO  TCP/IP  OR  OSI 

There  are  certain  requirements  for  ISDN  that  do  not  have  clear  correspondences 
within  the  structure  of  the  TCP/IP  or  OSI  models.  The  most  important  of  these  aspects 
are  listed  in  Figure  5.9. 

•  Multiple  Related  Protocols:  An  example  of  this  is  the  use  of  a  protocol  on  the 
D  channel  to  set  up,  maintain  and  terminate  a  connection  on  a  B  channel. 

•  Multimedia  Calls:  ISDN  will  allow  a  call  to  be  set  up  that  allows  information 
flow  consisting  of  multiple  quality  of  service  types  such  as  voice,  data, 
facsimile,  and  control  signals. 

•  Multipoint  Connections:  ISDN  allows  conference  calls  (i.e  multiple 
simultaneous  callers). 

Figure  5.9.  ISDN  requirements  not  directly  mapped  to  OSI.  From  (Stallings,  88). 
Leading  ISDN  manufacturers  have  been  collaborating  on  new  multiple  related 
protocols  for  bandwidth  management.  Bandwidth  management  is  needed  in  order  for 
ISDN  to  be  a  technically  sound  and  cost-efficient  solution  for  extending  a  LAN 
environment.  One  B  channel  provides  a  64  Kbps  bandwidth.  Combining  two  B  channels 
provides  a  128  Kbps  bandwidth  which  is  acceptable  to  adequately  perform  necessary 
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applications  in  the  LAN  environment.  By  collaborating  on  protocols,  ISDN 
manufacturers  are  trying  to  provide  standards  which  will  enable  equipment  from  different 
vendors  to  be  interoperable.  Some  protocols  have  already  become  an  Internet  standard, 
such  as  Point-To-Point  Protocol  (PPP)  (RFC  1661).  Others  are  only  proposed  protocols 
which  are  under  review  by  the  Internet  Engineering  Task  Force  (IETF).  Those  standards 
and  proposed  standards  which  are  necessary  for  an  extended  LAN  environment  are 
discussed  in  the  following  sections.  The  draft  specifications  for  proposed  standards  are 
outlined  in  a  series  of  documents  called  requests  for  comment  (RFCs). 

1.  Point-To-Point  Protocol  (PPP) 

Point-To-Point  Protocol  (PPP)  is  specified  in  (RFC  1661).  PPP  is  a  standard 
protocol  for  transmitting  network  data  over  point-to-point  links  using  modems  or  ISDN 
links.  Each  end  of  the  PPP  link  must  send  Link  Control  Protocol  (LCP)  packets  to 
establish,  configure  and  test  the  data  link  during  the  Link  Establishment  phase.  After  the 
link  is  established,  PPP  provides  for  an  Authentication  phase  before  proceeding  to  the 
Network-Layer  Protocol  phase.  The  current  PPP  authentication  protocols  are  used  to 
determine  identifiers  associated  with  each  system  connected  by  the  link.  (Simpson,  94) 

2.  Multilink  Protocol  (MP) 

Multilink  Protocol  (MP)  proposes  a  method  for  splitting,  recombining  and 
sequencing  datagrams  across  multiple  logical  data  links.  BRI  and  PRI  ISDN  both  offer 
the  possibility  of  opening  multiple  simultaneous  channels  between  systems,  giving  users 
additional  bandwidth  on  demand  (for  additional  cost).  By  means  of  a  four-byte 
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sequencing  header  and  simple  S5mchronization  rules,  packets  can  be  split  among  parallel 
virtual  circuits  between  ISDN  systems  in  such  a  way  that  reordering  of  packets  is 
minimized.  This  process  of  splitting  and  recombining  packets  reduces  latency  and 
potentially  increases  the  effective  maximum  receive  unit  (MRU)  packet  size. 

(Sklower,  96) 

Once  the  communication  link  is  established  as  addressed  in  the  PPP  section,  the 
receiving  system  indicates  to  the  other  system  that  it  is  capable  of  combining  multiple 
physical  links  by  responding  to  multiple  authentication  identifiers.  MP  is  specified  in 
(RFC  1990)  and  is  on  track  to  becoming  a  standard. 

Using  MP,  ISDN  can  provide  a  virtual  link  with  greater  bandwidth  than  a  single 
B  channel  (up  to  128  Kbps).  This  higher  bandwidth  is  essential  to  adequately  maintain 
acceptable  data  speeds  to  operate  applications  across  an  extended  LAN.  Applications 
used  in  this  case  study  to  test  whether  ISDN  provides  adequate  bandwidth  are  the  new 
MBone  tools  {vat  4.0b2,  rat  2.6a2,  vie  2.8).  The  new  MBone  tools  only  need  a 
bandwidth  of  up  to  128  Kbps  to  provide  adequate  voice  and  video  quality  for  VTC 
(Wood,  96).  MBone  and  its  requirements  are  addressed  later  in  this  chapter, 
a.  Bonding  vs.  MP 

Many  vendors  claim  that  their  ISDN  equipment  has  “bonding” 
capabilities.  Bonding  allows  for  the  two  B  channels  to  be  effectively  combined  into  a 
128  Kbps  transmission.  This  is  usually  a  hardware  bonding  which  is  not  a  virtual  link.  It 
is  a  proprietary  implementation  of  MP,  a  non-standard  kind  of  multilink,  and 
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interoperability  problems  are  an  issue  if  it  is  not  supported  identically  by  the  ISDN 
equipment  at  both  ends. 

The  Experimental  Results  chapter  in  this  thesis  tests  whether  SGI  Indy  computers 
(which  are  ISDN  capable)  can  achieve  an  aggregate  128  Kbps  IP  data  transfer.  Since 
both  computers  are  SGI,  there  is  no  way  to  verify  whether  the  bonding  that  is  performed 
by  the  ISDN  equipment  is  a  proprietary  function  or  one  that  satisfies  the  standard. 

3.  Compression  Control  Protocol  (CCP) 

CCP  is  a  proposed  standard  which  will  support  adding  compression  to  ISDN 
communication  to  generate  data  transmission  speeds  up  to  512  Kbps  on  a  nominal  128 
Kbps  BRI  line.'^  The  512  Kbps  effective  rate  is  a  4: 1  ratio  over  the  128  Kbps  which  users 
get  when  using  MP. 

Many  vendors  already  have  a  built-in  compression  scheme.  However  if  the  same 
(often  proprietary)  compression  scheme  is  not  identically  supported  by  the  ISDN 
equipment  at  both  ends  in  the  same  way,  compression  will  not  work.  The  Indys  used  for 
this  case  study  have  a  built-in  compression  scheme. 

CCP  will  allow  two  devices  to  determine  which  type  of  compression  algorithm 
each  supports  and  then  communicate  accordingly.  Presently  vendors  have  not  agreed  on 
a  standard  because  there  are  still  too  many  compression  algorithms  to  choose  among. 


'‘CCP  effectiveness  is  dependent  on  the  t5q3e  of  data  being  transmitted.  Many 
applications  use  compression  algorithms  that  produce  transmission  data  which  can  not  be 
compressed  further. 
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The  MBone  tools  are  applications  which  already  use  compression  schemes  to 
provide  low-bandwidth  audio  and  video.  Packetized  data  streams  produced  by  these 
tools  are  not  affected  by  the  ISDN  equipment’s  built-in  compression  scheme.  Most 
image  formats  also  include  native  compression.  Therefore,  from  an  Internet  user’s 
perspective,  CCP  only  has  a  noticeable  effect  on  plain  text,  HTML  text  and 
uncompressed  data  files. 

4.  Other  Proposed  Protocols 

There  are  many  other  proposed  protocols  for  bandwidth  management  under 
review  by  the  IETF.  Figure  5. 10  lists  a  few  of  these  protocols.  RFCs  and  proposed  draft 
RFCs  for  these  protocols  can  be  reviewed  on  the  Internet.  Knowledge  of  these  protocols 
are  not  necessary  for  the  purpose  of  this  thesis  and  therefore  will  not  be  addressed 
further. 

•  B  ACP  -  Bandwidth  Allocation  Control  Protocol  gives  users  a  way  to  add 

ISDN  lines  or  channels  as  needed,  and  drop  them  when  the  extra 
bandwidth  is  no  longer  needed.  (Richards,  96) 

•  RSVP  -  Resource  reSerVation  Protocol  will  enable  routers  to  reserve 

bandwidth  for  time-sensitive  data  transmission.  (Braden,  96) 

•  MP+  -  Multilink  Protocol  Plus  is  an  outgowth  of  MP  developed  by  Ascend 

Corporation  for  bonding  bearer  channels.  (RFC  1934) 

Figure  5.10.  Proposed  Standards. 

E.  IP  MULTICAST 

IP  multicast  is  a  protocol  for  transmitting  IP  datagrams  from  one  or  more  sources 
to  many  destinations  in  a  LAN  or  WAN  which  use  the  TCP/IP  suite  of  protocols.  The 
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basic  service  provided  by  IP  multicast  only  applies  to  UDP  which  was  briefly  discussed 
earher  in  this  chapter.  In  multicast  UDP  the  application  sends  a  single  message  to  one  or 
multiple  recipients.  The  service  is  unreliable,  meaning  that  erroneous  packets  are  not 
automatically  retransmitted.  Thus,  there  is  no  guarantee  that  a  given  packet  reached  all 
intended  recipients  which  belong  to  the  multicast  group.  This  t5T)e  of  service  is  suitable 
for  the  streaming  applications  usually  used  on  the  MBone.  The  MBone  is  more 
concerned  with  performance  than  reliability,  particularly  since  automatic  retransmission 
of  streamed  data  is  often  undesirable.  (Macedonia/Brutzman,  94) 

There  are  three  fundamental  types  of  addressing  mechanisms  in  the  current 
Internet  Protocol  (IPv4);  unicast,  broadcast  and  multicast.  A  unicast  address  is  designed 
to  transmit  a  datagram  to  a  single  destination.  All  packet  transfer  with  a  unicast  address 
is  inherently  point-to-point.  If  a  node  wants  to  send  the  same  information  to  many 
destinations  using  a  unicast  transport  service,  it  must  perform  a  replicated  unicast  and 
send  many  copies  of  the  data  to  each  destination  in  turn.  The  basic  facility  provided  by 
the  TCP  protocol  is  a  unicast  addressing  service.  (Stevens,  94) 

Broadcasting  is  sending  a  single  packet  addressed  to  all  hosts  on  a  network.  This 
places  an  uimecessary  processing  load  on  hosts  that  aren’t  interested  in  the  broadcast. 
Network  segments  and  hosts  can  become  overloaded  with  the  large  amounts  of  broadcast 
network  traffic.  Broadcast  addresses  are  specially  reserved  IP  numbers. 

With  a  multicast  service,  an  application  can  send  one  copy  of  each  packet  and 
address  it  to  a  group  of  computers  that  want  to  receive  it.  This  technique  addresses 
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packets  to  a  group  of  receivers  rather  than  to  a  single  receiver,  and  it  depends  on  the 
network  to  forward  the  packets  to  the  networks  that  need  to  receive  them.  For  example, 
computer  can  run  an  audio  and  video  application  and  each  single  packet  of  digitized 
audio  and  video  information  generated  by  the  application  will  be  received  by  multiple 
computers.  With  a  multicast  group,  each  node  or  computer  can  be  physically  located 
anywhere.  Packet  delivery  is  provided  to  hosts  that  have  subscribed  to  the  multicast 
address  of  interests. 

1.  Multicast  Backbone  (MBone) 

The  Multicast  Backbone  (MBone)  successfully  extends  multicast  addressing  to 
the  global  Internet.  When  using  the  MBone  tools,  any  host  with  appropriate  multicast- 
capable  software  can  establish  a  multicast  group  (also  called  a  session)  by  selecting  a 
multicast  address  and  then  announcing  the  group  address  and  session  lifetime  to  the 
Internet.  Hosts  are  free  to  join  or  leave  multicast  sessions  at  any  time.  A  single  host  can 
be  a  member  of  many  multicast  groups  simultaneously.  Strictly  speaking,  a  host  does  not 
have  to  be  a  member  of  a  particular  group  to  send  traffic  to  that  group  (although 
membership  is  usually  an  application  requirement).  When  the  number  of  members  in  a 
multicast  group  drops  to  zero,  the  group  is  essentially  removed  from  the  Internet  and  the 
multicast  address  is  freed  to  be  used  for  another  session.  (Macedonia/Brutzman,  94) 

This  thesis  uses  the  MBone  tools  to  test  whether  ISDN  supports  native  IP 
multicasting.  Failure  to  support  multicast  is  noncompliance  with  TCP/IP.  If  ISDN 
supports  multicasting  and  two  B  channels  can  be  effectively  combined  to  provide  the 


necessary  bandwidth  for  MBone,  then  ISDN  can  be  considered  as  a  technically  feasible 
solution  in  extending  the  LAN  environment.  The  Experimental  Results  chapter  tests 
whether  ISDN  on  SGI  Indy  systems  supports  channel  combination  and  ff  multicasting. 

F.  ECONOMIC  ANALYSIS 

ISDN  basic  rates  for  the  standard  configuration  of  2B+D  in  the  U.S.  are  included 
as  Appendix  B.  Figure  5. 1 1  is  an  example  economic  analysis  for  the  NFS  STL  based  on 
PacBell  rates  (Pacific  Bell,  96).  PacBell’s  tariff  is  lower  than  the  other  RBOCs.  These 
rates  (provided  to  NPS  in  March,  1996)  change  periodically.  New  users  installing  ISDN 
outside  the  PacBell  area  need  to  reverify  Figure  5.11  price  quotes. 

This  analysis  makes  several  reasonable  assumptions,  assuming  that  the  user  has 
MBone-compatible  Personal  Computers  (PCs)  or  workstations  equipped  with 
microphones  (and  optional  cameras).^  Therefore  computer  hardware  costs  are  not 
included  in  this  analysis.  MBone  software  is  free. 

PacBell  installation  charges  are  waived  if  the  user  commits  to  use  ISDN  for  more 
than  two  years.  Monthly  administrative  costs  were  determined  to  be  zero  for  this  case 
because  a  network  administrator  is  needed  regardless  of  the  choice  of  network.  In  our 
case,  the  NPS  STL  already  has  several  administrators.  If  both  ends  of  the  system  belong 
to  the  paying  organization,  then  the  setup  and  monthly  user  costs  need  to  be  multiplied  by 
2. 


^Hardware  requirements  are  addressed  in  Chapter  VI. 
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Startup  Cost: 


Line  Installation: 

Single  Line  Installation  (Business  Service)  $  71 

*ISDN  Basic  Line  Installation  (125)  0 

**Hardware  Costs: 

Nil  200 

ISDN  PC  Adapter  Card  500 

ISDN  Hub  (optional,  for  up  to  6  multiple  ISDN  lines  or  PRI  port)  4,000 

Administrative  Costs  (Network  Management) 

Training  (PacBell  application-oriented  and  Vendor  oriented)  0*** 

(tuition  costs  range  from  $500  to  $1,000) 


*  PacBell  will  waive  the  125.00  installation  fee  if  user  agrees  to  2  years  of  service 
**This  analysis  assumes  user  has  workstations.  Hardware  costs  are  available  at 
http://ymw.shoplet.com/hca-dware/db/905591.html 

***  System  administrator  did  not  attend  any  training.  This  thesis  research  provided 
requisite  training. 


Recurring  Costs: 

Monthly  Single  Line  ISDN  Usage  Fee 

$26 

Administrative  Costs  (Network  Management) 

0 

Annual  total  per  line 

$312 

Total  Costs  for  one  Line: 

$1,100 

Total  Costs  for  ten  Lines  (STL  plan) 

7,400* 

*The  cost  was  calculated  by  taking  the  price  to  install  one  PRI  line  +  (monthly  charge 
for  PRI  line  x  12)  +  ISDN  hub.  $750+(220xl2)+$4,000=$7,400 

Figure  5.11.  Example  ISDN  economic  analysis  for  NPS  Systems 
Technology  Lab  (STL). 
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G.  SUMMARY 

The  development  of  standards  for  ISDN  includes  the  development  of  protocols 
for  interaction  between  ISDN  users  and  the  network,  and  for  interaction  between  one 
ISDN  user  and  another.  These  protocols  can  be  mapped  against  the  P  and  OSI  reference 
models  to  explain  why  it  is  technically  feasible  to  run  P  over  ISDN.  However  there  are 
additional  requirements  for  ISDN  that  are  not  directly  described  within  the  P  and  OSI 
reference  models.  Unique  features  of  the  ISDN  reference  model  and  the  ISDN  protocols 
are  enumerated  in  detail. 

Multicast  is  an  P  standard.  Failure  to  support  multicast  is  noncompliance  with 
TCP/P.  If  ISDN  is  used  to  extend  an  P  network,  then  ISDN  needs  to  support  P 
multicasting.  If  multicasting  is  supported  and  two  B  channels  can  be  bonded  by  using 
MP,  then  the  MBone  tools  can  be  used  as  a  desktop  VTC  system  in  an  extended  LAN 
environment  The  technical  feasibility  of  this  assumption  is  tested  in  the  Experimental 
Results  chapter. 
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VI.  ISDN-RELATED  HARDWARE 


A.  INTRODUCTION 

The  combined  voice  and  data  capabilities  of  ISDN  support  a  broad  range  of 
applications.  However,  unlike  traditional  POTS  phone  lines  which  all  work  alike,  ISDN 
lines  must  be  specially  configured  by  the  phone  company  to  support  the  user’s  intended 
applications.  For  example,  the  LAN-extension  environment  described  in  Chapter  V  only 
supports  telecommuting  functions  which  are  concerned  with  IP-compatible  data  only. 
Therefore  the  corresponding  ISDN  line  ordered  is  a  2B+D,  data  only  line.  The 
configuration  setup  for  this  line  is  diflFerent  than  the  configuration  for  the  user  who  wants 
simultaneous  voice  and  data  traflSc  or  a  room-sized  VTC  application. 

The  actual  ISDN  connections  for  these  applications  have  unique  and  incompatible 
specifications  which  require  different  CPE  equipment.  This  chapter  is  concerned  with 
the  equipment  setup  for  an  extended-LAN  environment  addressed  in  Chapter  IV. 

Section  B  explains  an  ISDN  topology.  It  uses  reference  points  to  define  the 
communication  between  the  different  devices  and  the  parameters  for  the  functional 
devices.  Section  C  identifies  the  actual  equipment  used  in  this  thesis. 

B.  ISDN  WIRING 

ISDN  is  a  digital  technology  which  employs  essentially  the  same  t5q)e  of  copper 
wires  used  for  regular  telephone  service.  However  the  wiring  configurations  for  ISDN 
operate  differently.  The  Electronic  Industries  Associations  and  the  Telecommunications 
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Industry  Association  standard  (EIA/TIA)  for  wiring  analog  and  ISDN  service  requires  an 
unshielded  twisted-pair  (UTP)  cable  of  category  3  or  above.  The  ISDN  cable  needs  to  be 
33  feet  or  less  from  the  Network  Termination  device  (NTl)  to  the  ISDN  equipment. 
(Tittle/James,  96) 

The  demarcation  point  (DP)  is  the  dividing  line  between  the  telephone  company’s 
wiring  and  the  premises  wiring.  This  point  can  occur  either  inside  or  outside  the 
building.  If  the  DP  is  outside,  the  dividing  line  is  at  a  junction  box.  If  the  DP  is  on  the 
inside,  the  dividing  line  is  at  a  terminal  block.  From  the  DP  inward,  the  telephone  wiring 
is  the  user’s  responsibility.  The  demarcation  point  is  also  known  as  the  network  interface 
(NI). 

ISDN  and  POTS  outlets  look  exactly  alike  but  differ  in  the  connection  jacks; 
ISDN  uses  an  8-wire  RJ-45  jack  and  POTS  uses  a  6-wire  RJ-1 1  jack.  Neither  ISDN  nor 
POTS  uses  all  available  wires.  With  ISDN  only  4  of  the  8  pins  are  used.  Most  ISDN 
documentation  states  that  you  can  use  the  RJ-1 1  jack  and  don’t  need  to  install  an  RJ-45 
jack.  Such  documentation  claims  that  “the  telephone  company  won’t  tell  you  this  and 
will  charge  you  for  the  unnecessary  jack”  (Leeds,  1996).  To  avoid  connector 
compatibility  problems,  this  author  recommends  using  the  recommended  RJ-45  jack. 
ISDN  has  too  many  complex  issues.  It  is  safer  to  use  a  standard  that  has  been  proven  to 
work  than  to  second  guess  compatibility  issues  with  personally  rewired  adapter  jacks. 

In  this  case  study,  the  user  did  not  have  a  choice  in  the  line  hookup.  NPS  is  a 
military  installation.  All  telecommunication  requests  go  through  NPS  Base 


Communications  personnel,  who  contract  with  PacBell  for  the  installation  of  ISDN  lines. 
Presently  there  are  no  technical  service  employees  at  NPS  Base  Communications  that 
are  familiar  with  ISDN.  Unfortunately,  at  the  time  of  the  hookup,  there  were  no  system 
administrators  present  to  ask  the  PacBell  serviceman  questions. 

ISDN  circuits  are  implemented  by  the  provider  as  two-wire  copper  circuits  from  a 
central  office  within  3  miles  of  the  user’s  demarcation  point.  It  should  be  noted  that  this 
3-mile  limit  is  the  biggest  barrier  to  widespread  delivery  of  ISDN  service.  The  standard 
telephone  wiring  can  only  transmit  a  signal  for  three  miles  without  putting  in  repeaters  to 
extend  the  distance.  Repeaters  make  the  delivery  of  ISDN  expensive. 

The  RJ-45  ISDN  interface  is  also  known  as  a  two-wire  U  interface,  which  is 
defined  by  CCITT  as  the  demarcation  point  of  the  two- wire  ISDN  subscriber  loop.  The 
U  interface  is  then  connected  to  an  NTl  device.  The  NTl  represents  the  boundary  to  the 
ISDN  network  from  the  end-user  side.  The  NTl  includes  the  physical  and  electrical 
termination  functions  of  ISDN  on  the  customer  premises.  The  physical  function  of  the 
NTl  device  is  that  it  provides  an  interface  between  the  twisted-pair  wires  used  by  the 
telephone  company  in  the  BRI  and  the  eight-wire  cables  used  by  ISDN  equipment.  This 
is  called  the  S/T  interface.  The  electrical  function  of  the  NTl  is  to  act  as  the  power 
source  for  operating  the  ISDN  line.*  (Leeds,  1996) 

Each  BRI  access  has  only  one  NTl  device.  A  separate  S/T  reference  point  in  the 
NTl  device  will  provide  direct  multipoint  connection  of  ISDN  devices.  Multipoint 
configuration  refers  to  the  operation  of  multiple  devices  on  an  ISDN  line.  These  multiple 

*  Unlike  POTS,  if  there  is  a  power  failure,  ISDN  stops  working. 
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devices  include  digital  phones,  digital  faxes,  and  integrated  voice/data  terminal  devices. 

It  is  important  to  note  that  in  order  to  run  multiple  devices  on  one  line,  all  ISDN 
equipment  must  support  the  multipoint  protocol.  If  any  equipment  only  supports  point- 
to-point,  then  no  other  device  can  be  used  in  conjunction  with  it. 

The  NTl  can  be  a  stand-alone  device  or  it  can  be  embedded  in  a  specific  device. 

It  is  important  to  note  that  if  the  NTl  is  embedded  in  a  specific  device  (such  as  a  PC  with 
a  remote  access  adapter  card)  it  will  restrict  the  use  of  the  ISDN  connection  to  that 
device.  In  this  example,  the  user  will  only  be  able  to  use  the  BRI  line  for  that  PC,  unless 
the  PC  has  additional  ports  to  connect  other  ISDN  devices.  Most  documentation 
recommends  using  a  stand-alone  NT  1 ,  because  as  stated  above,  for  each  ISDN  line  there 
can  be  only  one  NTl .  A  stand-alone  NTl  was  used  in  this  thesis. 

There  are  two  types  of  devices  that  can  connect  to  an  S/T  interface:  terminal 
adapters  (TAs)  and  terminal  equipment  (TEl).  In  an  ISDN  implementation,  the  TA 
device  is  a  protocol  converter  that  adapts  equipment  not  designed  for  ISDN.  The  TA 
provides  an  R  reference  point,  which  lets  non-ISDN  analog  serial  data  terminal  devices 
(such  as  modems,  fax  machines,  POTS  telephones,  and  routers)  to  connect  to  the  NTl 
device  for  ISDN  service.  Devices  that  require  a  TA  are  called  TE2  devices.  TAs  are 
being  phased  out  because  more  and  more  equipment  is  designed  to  be  ISDN  ready  (TEl). 
ISDN  venders  also  market  TAs  that  include  the  NTl  function  as  well  as  support  non- 
ISDN  devices  (Leeds,  1996).  Only  one  TEl  was  connected  to  the  NTl  used  in  this 
thesis. 
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Figure  6. 1  shows  a  simple  ISDN  hookup.  The  reference  points  in  Figure  VI.  1 
define  the  communication  between  the  different  devices  and  the  parameters  for  the 
functional  devices.  They  are  consecutive  letters  of  the  alphabet  chosen  by  CCITT  to 
identify  a  set  of  standards.  This  enables  vendors  and  users  to  refer  to  their  equipment  in 
similar  terms. 


Figure  6.1.  Simple  ISDN  hookup.  From  (Beckman,  95). 


C.  IDENTIFYING  ISDN  APPLICATION  EQUIPMENT 

User  application  requirements  drives  the  equipment  selection  process.  The  most 
important  factor  to  consider  is  interoperability.  Every  ISDN  connection  has  two  ends  and 
the  equipment  at  each  end  (which  may  vary)  must  be  compatible  for  communications  to 
succeed. 

If  the  user  is  providing  the  equipment  at  both  ends,  buying  fi'om  a  single  vendor 
vastly  reduces  compatibility  problems.  Single-source  buying  isn’t  always  possible, 
however,  and  is  not  an  option  when  using  ISDN  to  connect  to  an  Internet  Service 
Provider  (ISP).  In  such  cases,  the  user  can  obtain  a  list  of  compatible  equipment  from  the 
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ISP.  In  this  case  study,  connection  to  the  Internet  is  made  through  the  NPS  connections 
and  the  equipment  on  both  ends  of  the  ISDN  lines  are  SGI  Indy  workstations. 

Some  hardware  features  such  as  data  compression,  bandwidth  on  demand 
(BOND)  and  dial-back  security,  are  proprietary  to  specific  vendors.  Others,  such  as 
password  security  and  multichannel  bonding,  have  defined  standards  that  are  supposed  to 
guarantee  interoperability.  However,  experience  has  shown  that  ISDN  standards  leave 
room  for  vendor  interpretation.  There  are  web  sites  which  show  many  users  fiustrated 
because  of  standards  that  are  not  truly  standards.  A  user  can  get  this  information  by 
doing  a  web  search  of  ISDN  fi-equently  asked  questions  (FAQs)  or  the  ISDN  User’s 
Group.  Current  links  are  located  on  Dan  Kegel’s  ISDN  home-page  (Kegel,  96). 

Each  model  of  ISDN  equipment  has  a  different  setup  using  different  configuration 
commands.  Vendors  of  ISDN  equipment  are  trying  to  make  setup  easier  for  the  user  by 
having  on-line  manual  pages  and  CD-ROMs  which  are  already  programmed  for  the  setup 
procedure.  However  as  noted  in  the  Experimental  Results  chapter,  the  setup  procedures 
are  not  always  what  this  author  would  call  user  idiot-proof  Even  the  experienced 
administrator  finds  it  difficult  to  interpret  the  commands  of  the  on-line  setup  or  the 
instructions  of  a  manual.  After  many  faistrating  hours  trying  to  configure  the  equipment, 
the  user  often  has  to  resort  to  vendor  technical  representatives  for  information. 

Another  important  problem  diagnosis  action  it  to  call  the  phone  company  to 
ensure  that  the  ISDN  line  is  working  properly  and  the  phone  company  ISDN  switches  are 
configured  properly.  This  too  can  be  a  trying  experience  because  it  may  take  a  couple  of 
days  for  the  representative  to  call  the  user  back.  When  they  do  call,  technical 
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representatives  cannot  see  or  directly  diagnose  the  problem  over  the  phone  line. 

Therefore  correcting  the  problem  is  sometimes  a  best-guess  effort  and  finding  the 
solution  often  becomes  a  hit-or-miss  trial.  These  issues  are  painstakingly  documented  in 
the  Experimental  Results  chapter. 

1.  NTl 

A  Motorola  NT  ID  is  the  Network  Termination  device  (NTl)  that  was  used  for  the 
case  study.  It  costs  about  $200  and  includes  the  standard  two  S/T-interface  ports.  It  was 
purchased  through  the  DoD  procurement  system  as  a  credit  card  purchase.  Figure  6.2 
shows  an  NTID. 


The  Motorola  NTID  is  designed  for  the  ISDN  basic  rate  communication  system. 
As  shown  in  figure  6. 1,  it  installs  between  the  Central  Office  (CO)  U  interface  and  the 
Customer  Premise  (CP)  S  or  T  interface.  Both  point-to-point  and  point-to-multipoint 
configurations  are  supported.  This  case  study  only  used  the  point-to-point  configuration. 
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There  are  six  light-emitting  diodes  (LEDs)  on  anNTl.  Each  LED  indicates  that 
the  NTl  is  performing  a  certain  function.  Figure  6.3  explains  the  functions  of  the  six 
LEDs  on  the  front  of  the  NTl .  Figure  6.4  shows  a  closeup  snapshot  of  the  rear  panel  of 
the  Motorola  NTl.  The  rear  panel  houses  (from  left  to  right)  the  power  jack,  one  four- 
position  dip  switch  for  terminating  resistor  selection,  two  jacks  for  either  an  S  or  T 
interface  to  the  CP  equipment,  and  one  U  jack  for  connection  to  the  CO. 
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LED 

DESCRPTION 

SC  (Sealing  Current) 

When  on,  this  LED  indicates  the  ISDN  switch  has 
bounced  back  a  termination  test  voltage  from  the  NTID. 

ACT  (Activity) 

When  on,  this  LED  indicates  that  a  link  between  the 
terminal  equipment  and  the  ISDN  switch  at  the  phone 
company  via  the  NTID  has  been  established. 

If  a  disruption  occurs  between  the  U-interface  and  the 
ISDN  switch,  this  LED  flickers. 

If  a  disruption  occurs  between  the  S/T-  interface  and  the 
Terminal  equipment,  this  LED  blinks  once  per  second. 

If  a  disruption  occurs  on  both  U-  and  S/T-  interfaces, 
this  LED  goes  off. 

LB  (Loop  Back) 

When  on,  this  LED  indicates  the  ISDN  switch  has  sent  a 
2B+D  loopback  command  to  the  NTID. 

LP  (Local  Power) 

When  on,  this  LED  indicates  the  local  AC  power  is 
active. 

RP  (Remote  Power) 

When  on,  this  LED  indicates  the  power  at  the  remote 
site  is  functional. 

RPR  (Remote  Power 
Reversed) 

When  on,  this  LED  indicates  the  power  at  the  remote 
site  is  not  functioning  properly. 

Figure  6.3.  Functions  ofthe  LEDs  on  the  NTID.  From  (Angell,  1995). 
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Figure  6.4.  Closeup  snapshot  of  rear  panel  of  Motorola  NTID. 

a.  NTI  Hookup 

To  connect  the  NTI,  the  supplied  U  cable  inserts  into  the  U  jack  on  the 
NTI  and  the  opposite  end  connects  to  the  ISDN  wall  jack.  Similar  cables  are  used  to 
connect  the  S/T  jacks  to  the  designated  TEl  or  the  TA  (R  interface).  In  this  case,  the 
NTI  was  connected  to  an  SGI  Indy  workstation  which  is  ISDN  capable. 

2.  Terminal  Adapters 

There  are  two  types  of  remote  access  devices  that  Avill  connect  to  a  PC:  a  bus 
adapter  card  and  a  stand-alone  unit.  The  bus  adapter  cards  are  cheaper  than  the  stand¬ 
alone  solution.  Bus  cards  use  the  PC  bus  configuration  to  communicate  fi-om  the  user’s 
PC  to  the  terminal  adapter.  The  cards  support  Ethernet  or  serial  communication. 

A  stand-alone  ISDN  bridge  looks  like  a  standard  modem  and  requires  a  LAN 
adapter  in  the  PC.  A  bridge  connects  separate  physical  networks  into  a  single  logical 
network  that  behaves  as  though  it  were  a  single  physical  network.  The  PC  only 
communicates  via  Ethernet  to  the  ISDN  bridge.  The  Ethernet  card  connects  to  the  ISDN 
bridge  via  thin  Ethernet  coaxial  cable  or  an  RJ-45  cable.  (Angell,  1995) 


The  stand-alone  ISDN  bridge  is  a  TA  which  connects  the  R  interface  to  the  S/T 
interface.  In  this  case  study,  ISDN  capable  workstations  were  used  which  had  the  bus 
adapter  cards.  An  R  interface  was  not  needed. 

3.  ISDN-Capable  Workstations 

Originally  the  NPS  STL  ISDN  connection  plan  was  to  connect  an  SGI  Indy 
Presenter  named  baby.stl.nps.nayy.mil  (baby)  remotely  to  the  graphics  lab  network  in 
Spanagel  Hall  via  ISDN.  SGI  Indy  Presenters  always  include  an  ISDN  interface,  baby 
was  connected  to  an  SGI  Indy  workstation  named  rambo.cs.nps.navy.mil  (rambo).  rambo 
is  hooked  up  to  a  different  Ethernet  LAN  as  well  as  to  a  different  ISDN  connection. 

To  avoid  sharing  conflicts  with  other  students  and  instructors  over  baby,  it  was 
decided  halfway  through  the  testing  to  hook-up  and  configure  an  SGI  Indy  workstation 
in  the  STL  for  ISDN.  The  workstation  used  is  a  standard  Indy  named 
steel.stl.nps.navy.mil  (steel),  also  equipped  with  a  video  camera  and  microphone. 

4.  Video  Conferencing  Equipment  (MBone) 

Figure  6.5  shows  how  two  computers  can  be  connected  together  using  ISDN  and 
have  a  desktop  VTC.  The  only  hardware  needs  for  MBone  applications  is  a  video 
camera  that  sits  on  top  of  the  PC  and  a  microphone.  As  stated  above,  the  Indy 
workstations  are  equipped  with  a  camera  and  microphone.  Video  cameras  are  only 
needed  for  sending  video,  since  generating  received  networked  video  is  performed  in  the 
software. 
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Figure  6.5.  Desktop  video  systems.  From  (PacBell,  94). 


D.  SUMMARY 

The  actual  ISDN  line  connections  used  for  ISDN  applications  have  unique  and 
incompatible  specifications  which  require  different  equipment.  This  chapter  is  concerned 
with  only  the  equipment  needed  for  the  LAN  extension  environment  addressed  in 
Chapter  V.  It  describes  hardware  considerations  for  communication  between  the 
different  devices  and  the  functions  of  those  devices. 
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Vn.  EXPERIMENTAL  RESULTS 


A.  INTRODUCTION 

The  area  of  focus  in  this  thesis  was  to  determine  if  BRI  ISDN  can  support  TCP/IP 
protocols,  especially  bonded  channels  and  native  ff  multicast.  In  theory,  TCP/IP  deals 
with  network  interactions  above  the  data  link  layer  of  the  OSI  model.  Therefore  IP  can 
run  over  any  data  link  and  physical  link  protocols.  ISDN  protocols  are  mainly  concerned 
with  the  data  link  and  physical  link.  Standards  require  that  multicasting  be  capability  of 
an  IP  network.  This  chapter  tests  whether  it  is  technically  feasible  to  perform  native  IP 
multicasting  over  ISDN,  so  that  ISDN  is  a  “true”  IP  network  extension  technology. 

Section  B  addresses  the  initial  plan  of  attack  for  installing  an  ISDN  line  and 
attempting  to  run  an  MBone  demonstration.  Section  C  addresses  how  the  workstations 
were  configured  to  run  ISDN.  Section  D  addresses  test  results  once  the  workstations 
were  configured. 

B.  MBone  DEMONSTRATION 

Part  of  the  experimentation  was  to  use  ISDN  to  connect  to  a  host  site  in  France. 
This  test  was  intended  to  determine  whether  the  ISDN  standards  were  world-wide  or 
nation-wide.  The  Fifth  Annual  World  Wide  Web  Conference  was  to  be  held  on  May  7, 
1996  in  Paris  France.  The  conference  was  being  transmitted  using  the  MBone.  The 
objective  was  to  telecommute  to  France  and  get  on  the  Internet  using  that  connection.  If 
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the  ISDN  standards  were  just  nation-wide,  we  would  telecommute  to  a  local  site  and  get 
Internet  access. 

There  were  two  weeks  to  get  a  line  installed  and  to  test  the  feasibility  of  using 
MBone  tools  over  ISDN.  Initially  a  line  was  to  be  installed  in  the  STL  in  Root  Hall  at 
NPS.  Base  Communications  had  ten  ISDN  lines  available  for  data  that  no  one  was  using. 
An  ISDN  jack  and  line  was  requested  to  be  installed  in  the  STL  in  order  to  be  connected 
to  one  of  the  available  lines. 

The  STL  had  a  portable  SGI  Indy  Presenter  named  bahy  that  was  never 
previously  used  for  ISDN.  The  graphics  lab  in  Spanagel  Hall  at  NPS  had  an  Indy 
workstation  named  rambo  that  was  already  connected  to  ISDN  as  well  as  being 
connected  to  the  Ethernet  LAN.  It  was  decided  to  hook  baby  to  ISDN  to  determine  if  it 
was  ISDN  capable  and  have  it  communicate  via  ISDN  with  rambo.  Once  baby  was 
telecommuting  with  rambo,  the  MBone  tools  would  be  tested.  Then  if  everything 
worked,  a  point  of  contact  in  Paris  would  be  established  for  a  trial  run  before  the 
conference. 

A  work  request  to  have  PacBell  come  to  NPS  and  install  the  jack  and  line  was 
generated  and  hand  carried  through  the  administrative  chain  of  command.  This  was  done 
to  shorten  the  wait  time  in  the  processing  queue  and  to  get  NPS  Base  Communications  to 
make  the  ISDN  line  request  high  priority. 

NPS  Base  Communications  was  unable  to  satisfy  the  request  to  install  a  jack  and 
line  because  of  the  short  time  constraint.  It  would  take  two-three  working  days  for 
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PacBell  to  come  in  and  install  the  line.  There  are  however  other  existing  ISDN  lines  at 
NPS  that  are  used  to  transmit  data.  One  line  was  in  an  office  in  Spanagel  Hall  that  was 
unused.  The  line  was  connected  to  an  ISDN  jack  but  did  not  include  an  NTl.  The 
original  work  request  was  modified  to  read  “connect  an  available  ISDN  data  line  in  NPS 
Base  Communications  to  Spanagel  Hall,  office  402B.”  NPS  Base  Communications  was 
able  to  satisfy  this  second  request.^ 

The  MBone  demonstration  of  this  conference  over  ISDN  did  not  take  place.  This 
failure  was  particularly  disturbing  because  it  was  intended  to  serve  as  a  backup  to  the 
school’s  primary  MBone  connectivity.  When  this  primary  MBone  link  went  down  10 
seconds  into  the  NPS  presentation  on  the  distributed  panel,  no  backup  ISDN  connectivity 
was  available.  Rather  than  NPS  discussing  future  uses  of  the  MBone,  NPS  demonstrated 
technical  failures  before  a  global  audience.  This  performance  is  unsatisfactory. 
(Brutzman,  96a) 

The  major  reason  why  the  MBone  demonstration  over  ISDN  did  not  work  was 
because  of  the  lack  of  technologically  proficient  personnel  at  NPS.  Initially  the  line  in 
Spanagel  402B  could  not  be  activated.  The  system  administrator  for  the  STL  tested  the 
setup  and  the  ISDN  equipment  configuration  for  two  days  before  giving  up  and  asking 
NPS  Base  Communications  to  test  the  ISDN  line.  In  order  to  get  technical  support  fi-om 


'The  first  work  request  eventually  had  to  be  rewritten  and  resubmitted  in  order  to 
get  an  ISDN  line  for  the  STL  for  future,  related  work. 
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PacBell,  Base  Communications  has  to  initiate  the  request  which  causes  additional  time 
delays.  It  took  two  days  for  NPS  Base  Communications  to  contact  PacBell.^ 

It  was  explained  by  NPS  Base  Communications  that  the  ISDN  switch  at  the 
Central  Office  (CO)  can  determine  whether  a  line  is  being  used  or  not.  It  pings  the  NTl 
to  verify  that  it  is  activated.  If  there  is  no  NTl  attached  to  the  line  or  the  NTl  is  powered 
off,  the  ISDN  switch  will  turn  the  connection  off.  The  office  in  Spanagel  Hall  had  a  line 
and  ISDN  jack  but  was  never  connected  to  an  NTl .  Apparently  this  caused  the  CO 
switch  to  turn  off  the  line.^ 

NPS  Base  Communications  personnel  are  not  currently  knowledgeable  about 
ISDN  and  therefore  thought  that  the  activation  of  the  existing  line  was  an  internal  job 
rather  than  a  job  for  PacBell.  Therefore  the  hook-up  of  the  ISDN  line  was  not  properly 
performed. 

Although  the  window  of  opportunity  was  closed  for  this  MBone  event,  we 
decided  to  continue  setting  up  an  ISDN  line  in  the  STL  to  determine  whether  it  was 
technically  feasible  to  use  MBone  over  ISDN.  The  scope  of  the  investigation  was 
narrowed  to  include  only  nation-wide  protocol  implementations  instead  of  world-wide 


^It  is  noted  that  the  request  to  Base  Communications  for  assistance  was  informally 
done.  Normally  a  work  request  needs  to  be  generated  before  Base  Communications 
performs  any  work.  This  would  have  taken  an  additional  1-2  weeks  to  route.  Base 
Communications  allowed  this  job  to  take  priority  because  of  the  time  constraint  of  the 
conference  and  the  fact  that  it  was  thesis  related. 

^This  is  Base  Communications  explanation  of  the  problem  with  the  line.  A  STL 
system  administrator  never  got  to  talk  with  the  technical  representatives  from  PacBell 
and  so  this  theory  was  not  verified. 
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protocol  implementation.  Once  ISDN  was  installed,  baby  would  connect  remotely  to 
rambo  to  test  MBone  operability. 

When  the  ISDN  line  was  eventually  installed  in  the  STL,  there  was  no  prior 
notification  by  NFS  Base  Communications  and  therefore  no  STL  system  administrators 
were  available  to  ask  questions  or  to  watch  the  installation.  This  was  fiustrating  because 
the  network  administrator’s  responsibility  is  to  support  and  maintain  new  technology  and 
equipment,  but  they  were  not  given  the  tools  or  knowledge  with  which  to  do  it.  No 
information  was  received  from  PacBell  or  NFS  Base  Communications  explaining  the 
BRI  channel  transmission  capacity  (64  Kbps  or  56  Kbps),  switch  type  or  software  used 
by  PacBell.  This  information  is  necessary  to  properly  setup  the  ISDN  equipment.  These 
problems  are  exhaustively  documented  here  because  we  believe  they  are  commonplace 
and  a  frequent  impediment  to  proper  ISDN  operation. 

To  avoid  sharing  conflicts  with  other  students  and  instructors  over  baby,  it  was 
decided  to  hookup  and  configure  another  SGI  Irufy  workstation  in  the  STL  for  ISDN. 
The  workstation  is  named  steel.stl.nps.navy.mil  (steel). 

C.  SETTING  UP  WORKSTATIONS 

1.  ISDN  User’s  Guide 

SGI  Indy  workstations  come  with  online  help  manuals  called  IRIS  InSight.  The 
ISDN  User’s  Guide  is  one  such  help  manual.  It  provides  information  about  setting  up  an 
Indy  ISDN  connection.  A  copy  of  this  guide  is  available  online  at 
http:/Avww.ngonet.ee:88/SGI_EndUser/ISDN_UG. 
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2.  Phone  Company  Services 

The  user  needs  to  order  2B  +  D  for  circuit-switched  data  only.'^  The  user  does 
not  want  X.25  (packet-switched  data)  or  voice-related  service.  Any  other  switch 
configuration  will  not  get  2B  channels  to  bond  properly. 

As  mentioned  in  Chapter  IV,  the  user  needs  to  know  which  type  of  switch 
hardware  and  switch  software  the  phone  company  uses.  Depending  on  the  type  of 
switch,  the  user  may  need  a  Service  Profile  Identifier  (SPED).  This  is  an  alphanumeric 
string  that  uniquely  identifies  the  service  capabilities  of  an  ISDN  terminal.  The  SPID  is 
an  identifier  that  points  to  a  particular  location  on  the  telephone  company’s  CO  switch 
memory  where  relevant  details  about  the  device  are  stored. 

As  mentioned  earlier,  there  was  no  NPS  system  administrator  present  to  obtain 
information  during  the  PacBell  line  installation.  Representative  documentation  was 
received  from  the  system  administrator  in  Spanagel  Hall  who  set  up  rambo  with  ISDN. 
That  documentation  indicated  that  PacBell  used  Custom  software  which  does  not  require 
a  SPED  for  setup.  Therefore,  it  did  not  appear  necessary  to  obtain  any  information  from 
the  phone  company. 

3.  UUCP,  PPP  and  ISDN  Software 

UUCP,  PPP  and  ISDN  software  are  all  needed  for  Indy  ISDN  connections  and 
superuser  privileges  are  required  to  install  them  on  workstations.  UUCP  software  is  a 
part  of  the  Irix  operating  system  software  but  it  is  not  installed  by  default.  UUCP,  PPP 

'‘Various  circuit-switch  line  configurations  are  addressed  in  Chapter  IV. 


and  ISDN  software  are  located  on  the  main  SGI  software  CD.  To  install  the  software  on 
an  SGI  workstation,  see  instructions  in  “Setting  up  the  ISDN  software”  in  IRIS  InSight 
help  manuals. 

4.  Configuration  Files 

steel  is  connected  to  the  fiber  distributed  data  interface  (FDDI)  backbone  on 
campus  as  well  as  ISDN.  For  this  case  study,  steel  was  to  represent  a  user’s  home 
computer  which  would  not  be  connected  to  a  fiber  network  or  any  other  network. 
Therefore,  steel  would  have  to  be  physically  disconnected  from  the  network  and  the  error 
messages  informing  the  user  that  the  cable  was  disconnected  had  to  be  suppressed.  A 
startup  script  was  created  to  do  this.  The  script  was  as  follows: 

/usr/etc/ifconf ig  xpiO  down 
cd  /etc/rc2.d 

In  -s  . ./init.d/isdn.no_ethernet  s31isdn.no_ethernet 
(All  typed  on  one  line) 

It  was  subsequently  decided  not  to  disconnect  steel  from  the  fiber  network 
because  steel  could  not  be  dedicated  only  to  this  case  study.  The  experiment  continued 
using  steel  on  two  simultaneous  networks;  FDDI  and  ISDN. 

To  set  up  ISDN  there  are  several  additional  files  to  configure.  The  following 
configuring  process  is  also  found  in  the  online  help  manual. 
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a.  /etc/hosts  File 

All  names  and  IP  addresses  corresponding  to  remote  hosts  and  local 
machines  are  placed  in  this  file  because  a  Domain  Name  Server  (DNS)  is  not  being  relied 
upon.  Remote  host  ramho  and  its  address  was  put  in  this  file  as  follows: 

131-12  0.7.49  rainbo.cs.nps.navy.mil  rambo 

h.  /etc/configAsdnd.  options  File 

In  this  file,  the  software  type  which  is  provided  by  the  telephone  company 
is  identified  to  the  ISDN  daemon.  The  ISDN  daemon  is  /usr/etc/isdnd  and  is  used  with 
Point-to-Point  Protocol  (PPP)  when  an  Indy  is  accessing  another  system  over  the  ISDN 
line.  The  file  includes  several  lines  of  information  that  tell  the  user  how  to  edit  the  file 
correctly.  Each  line  starts  with  a  pound  sign  (#)  to  indicate  that  the  hne  is  a  comment. 
The  user  removes  the  pound  sign  (#)  from  the  line  in  the  file  that  corresponds  to  the 
correct  switch  software  type.  In  this  case,  the  pound  sign  was  removed  from  the  line: 

-t  BESS 

This  command  line  was  chosen  because  as  stated  earlier  the  documentation  received  from 
the  system  administrator  in  Spanagel  Hall  indicated  switch  software  was  Custom. 

Once  this  is  done  the  ISDN  software  can  be  turned  on  by  the  root  superuser  by 

typing: 

/etc/chkconfig  isdnd  on 
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c.  /etc/ppp.conf  File 

For  each  system,  the  user  must  supply  three  lines  of  information  that 
include  the  host  name  of  the  system,  and  the  name  and  password  of  the  user  login 
account  on  that  system.  A  static  network  route  is  also  requested  using  add_route.  Each 
entiy  is  as  follows; 

<host  name>  send_username=<user  naitie> 

send_passwd=<password> 
add_route 

Thus  for  steel  the  /etc/ppp.conf  Sle  read: 
rambo  send_usernaine=baby 

send__pas  s  wd= 1  nnkam 
add_route 

outdevs=2  (This  line  will  be  explained  in  a  later  section) 

The  static  network  route  is  used  when  the  user  wants  the  datagrams  to  be  routed 
solely  through  the  ISDN  line.  The  routing  daemons  are  turned  off.  The  routing  daemons 
used  on  the  NFS  systems  are  the  programs  routed  ecoA  gated. 

If  the  user  wanted  both  the  ISDN  and  the  fiber  network  running  simultaneously, 
the  routing  daemons  are  configured  differently.  The  add_route  line  in  this  file  is 
removed.  If  the  static  route  and  the  routing  daemon  are  used  at  the  same  time,  routing  is 
be  disrupted  and  the  remote  system  will  not  be  reached.  A  detailed  description  of  these 
considerations  can  be  found  on  the  online  IRIS  manual  pages. 
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d.  /etc/uucp/Devices  File 

It  needs  to  be  defined  in  this  file  what  device  files  are  being  used.  The 
format  is  as  follows; 

ISDN  isdn/modein_bl-38400  direct 
ISDN  isdn/inodein_b2 -38400  direct 
e  /etc/uucp/Systems  File 

The  User’s  Guide  recommends  making  a  backup  copy  of  this  file  in  case  a 
default  version  is  needed  in  the  future.  The  permissions  on  the  original  file  need  to  be 
changed  by  the  root  superuser  so  the  file  can  be  edited.  The  following  information  needs 
to  be  added  for  each  system  in  the  following  format; 

<Host  name>  Any  ISDN  38400  ISDNCALL  [<rate>]  <phone 

noCONNECTED 

(All  typed  on  one  line) 

The  <Host  name>  is  rambo.  Any  refers  to  any  time  to  place  a  call.  ISDN  refers 
to  the  device  type.  38400  no  longer  has  any  meaning.  At  one  time,  38400  represented 
transfer  speed.  Now  it  is  filler  input  and  remains  a  required  entiy.  The  rate  refers  to  the 
rate  at  which  the  connection  will  transfer  data.  In  this  case  56  was  used.  The  line  ends 
with  the  word  CONNECTED.  It  is  important  that  there  is  a  space  between  each  item  in 
each  line.  That  is,  leave  a  space  after  Host  name.  Any,  ISDN,  38400,  both  sets  of  double 

quotes,  and  phone  number.  The  final  entry  appears  as  follows; 

rambo  Any  ISDN  38400  ISDNCa.ll  [56]  2005  CONNECTED 


5. 


steel  Needs  Access  To  rambo 


The  last  line  of  rambo' s  /etc/ppp.conf^Q  should  read: 

_ISDN_INCOMING  reconfigure 
This  is  needed  to  give  steel  access  to  rambo. 

6.  Restart 

When  all  editing  is  complete,  the  system  needs  to  be  restarted  so  the  above 
changes  can  be  recognized  by  the  operating  system  kernel. 

D.  TURNING  ON  THE  ISDN  CONNECTION 

Once  the  system  is  restarted  for  the  configuration  file  changes  to  take  effect,  only 
the  administrator  who  has  superuser  privileges  can  turn  on  and  test  the  connection.  A 
shell  window  was  opened  up  and  the  test  began.  The  administrator  tried  to  make  the 
ISDN  connection  between  steel  and  rambo  by  typing:  ppp  -  r  rambo.  After  several 
seconds,  if  successful,  the  connection  is  established  and  ready  to  use.  The  user  sees  a 
message  similar  to  the  following  when  a  connection  is  made: 

ppp[3001]:  rambo  IPCPl:  ready  131.120.7.116  to  131.120.7.49 
1.  ISDN  Connection  Fails 

The  first  attempt  (as  well  as  numerous  other  attempts)  ended  unsuccessfully.  The 
output  message  above  which  acknowledges  a  completed  connection  was  never  displayed. 
To  verify  that  the  remote  system  had  accepted  the  password  and  was  running  ppp, 
another  shell  window  was  opened  and  the  following  command  was  entered: 
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nets  tat  -C.  This  command  showed  the  status  of  the  different  network  ports.  The 
results  were  unsuccessful  and  inconsistent.  Sometimes  ecO  was  up  and  sometimes  the 

pppO  connection  never  appeared.^  A  successful  report  viill  look  something  like 


Name 

Mtu 

Network 

Address 

xpiO 

1500 

131.120.7 

131.120 .7.49 

224.0.0.2 

224.0.0.4 

224.0.0.1 

ecO* 

loO 

8304 

127 

127.0.0.1 

pppO 

1500 

(pt-to-pt) 

131.120.7.116 

224.0.0.1 

rambo  was  pinged  from  another  system  that  was  connected  via  FDDI.  It  was 
determined  via  FDDI  and  Ethernet  that  rambo  was  up.  The  system  administrator  for  the 
Graphics  Lab  in  Spanagel  Hall  was  called  to  ask  if  the  ISDN  line  on  their  side  was 
working.  It  was. 

A  confidence  test  on  steel  was  then  performed  to  make  sure  that  the  problem  was 
not  with  the  connection  between  the  NTl  and  the  TEl .  Information  on  how  to  run  a 
confidence  test  can  be  found  in  the  InSight  User’s  Guide.  The  notifier  confirmed  that  the 
ISDN  connection  was  ready  to  use  and  that  the  problem  was  not  with  the  CPE  or  the 
NTl. 

^The  connection  is  down  when  a  *  is  displayed  after  the  network  port. 
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Testing  continued  to  try  and  determine  which  file  on  steel  was  not  configured 
properly.  Then  another  shell  window  was  opened  and  the  following  command  was 
entered:  ISDNstat.  ZS'DTVs'tor  reports  the  progress  of  the  call.  The  call  to  romio  was 
placed  again.  Both  B  channels  were  idle.  It  showed  that  B1  channel  would  dial,  connect, 
disconnect  and  then  be  idle.  No  diagnostic  messages  were  provided  during  these  failures. 

Another  window  was  opened  and  ISDN  was  stopped  and  restarted.  The 
commands  for  this  is  as  follows : 

/etc/init .d/isdnd  stop 
/etc/killall  ppp 
/etc/init. d/isdnd  start 

Because  of  our  lack  of  experience  with  ISDN,  the  system  administrators  were  not 
confident  that  the  configuration  was  set  up  properly.  They  continued  to  search  for 
answers  within  the  confines  of  the  ISDN  equipment.  It  never  occurred  to  anyone  to 
check  with  PacBell  on  the  line  itself 

Another  test  was  performed  to  obtain  more  error  status  information.  This  was 
done  by  typing  the  -d  flag  after  the  command  ppp  -  r  raitibo  -  Additional  -d  flags 
produce  more  information.  SGI  Indys  allow  up  to  eight  different  -d  flags  to  the  ppp 
command  line  to  display  additional  information.®  A  printout  of  status  information  is 


^Additional  -d  flags  introduces  security  problems  because  passwords  are 
displayed. 
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attached  as  Appendix  C.  The  printout  was  given  to  the  Graphics  Lab  system 
administrator  in  Spanagel  Hall  to  evaluate. 

After  many  weeks  of  ISDN  working  periodically  and  failing  without  reason,  NPS 
Base  Communications  was  contacted.  The  supervisor  stated  that  PacBell  was  not  using 
Custom  but  5ESS  National  ISDN  1  (Nil).  SPID  numbers  were  required  for 
configuration  of  this  ISDN  software.  The  supervisor  stated  that  both  bearer  channels 
needed  a  SPID  number.  If  this  was  true,  then  /etc/config/isdnd.opttons  file  had  to  be 
changed  to  reflect  this  software  and  the  SPID  numbers.  Nil  is  the  switch  software  and 
the  command  line  is; 

-t  Nil  -s  <SPID1>  -s  <SPID2>  -n  <PN1>  -n  <PN2> 

The  SPID  numbers  are  the  ISDN  phone  number  with  01  at  the  beginning  and  0  at  the 
end.  Each  B  channel  has  a  SPID  number.  PN  numbers  are  the  7-digit  phone  numbers. 

Therefore  for  the  STL  ISDN  connection,  the  /etc/config/isdndoptions  file  now  reads: 

-t  Nil  -s  0165661280  -s  016566128  -n  6566128  -n  6566128 

Diagnostic  messages  stated  that  it  could  not  identify  SPID.  NPS  Base 
Communications  was  contacted  again  and  a  request  was  made  for  PacBell  to  check  the 
switching  software.  A  Base  Communication  technician  came  to  Root  Hall  and  checked 
the  line  and  determined  it  was  working  properly.  The  PacBell  representative  told  NPS 
Base  Communications  that  the  switch  for  Monterey  was  actually  a  5ESS  Custom  switch. 
The  configuration  was  changed  back  to  the  original  to  reflect  Custom  software. 

The  ISDN  connection  continues  to  work  intermittently.  It  has  not  been  resolved 
as  to  what  the  problem  is.  The  lines  were  tested  by  NPS  Base  Communications  and  they 
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passed.  No  errors  in  transmission  were  noted.  The  NTl  was  replaced  with  another  NTl 
to  determine  if  it  was  a  local  hardware  failure.  The  connection  came  up  the  first  time  and 
failed  several  times  after,  eliminating  the  NTl  as  the  cause  of  failure.  We  still  have  not 
identified  the  cause  of  these  intermittent  ISDN  line  failures. 

2.  Testing  MP 

The  Indy  supports  a  nonstandard  method  for  optimizing  connection  speed  and 
does  not  use  the  MP  standard.  In  order  to  bond  two  B  channels,  the  /etc/ppp.conffAt 
needs  to  be  amended.  The  following  line  needs  to  be  added:  outdevs  =  2 .  This 
command  sets  the  maximum  number  of  parallel  serial  lines  that  Avill  be  used. 

When  an  ISDN  connection  between  rambo  and  steel  was  made  successfully, 
transmission  speeds  were  tested.  This  test  simulated  remote  users  downloading  files 
fi'om  their  network  at  work.  A  new  shell  window  was  created  and  ISDNstat  was  run  to 
get  the  status  of  the  two  B  channels. 

Initially  the  ISDNstat  window  only  showed  the  B1  channel  connected  and  the  B2 
channel  idle.  A  1.2  Megabyte  (MB)  uncompressed  executable  file  was  transferred  fi'om 
steel  to  rambo.  ISDNstat  window  showed  that  the  B1  channel  was  transmitting  at  54-56 
Kbps.  The  file  was  transmitted  again  using //^.  ftp  showed  that  the  transmission  was 
closer  to  85  Kbps.  If  it  were  not  for  the  ISDNstat  window,  a  user  will  likely  think  2 
channels  are  connected  because  of  the  fast  transfer  time  (>56  Kbps).  In  reality  ppp 
software  has  a  built-in  compression  algorithm  which  compressed  the  file  on-the-fly.  The 
debugging  script  shows  that  on-the-fly  compression  is  taking  place  rather  than  bonding 
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two  channels.  The  test  was  done  two  more  times  and  the  results  were  consistent  with  the 
first.  This  test  therefore  showed  that  an  effective  throughput  of  85  Kbps  was  possible  on 
a  single  B  channel. 

The  system  administrator  from  the  STL  in  Root  Hall  contacted  the  administrator 
in  Spanagel  Hall  about  the  two  B  channels  not  bonding.  Because  NPS  has  a  maintenance 
agreement  with  SGI  which  identifies  one  point  of  contact  for  all  of  NPS  dealing  with  SGI 
equipment,  the  administrator  in  Spanagel  Hall  is  the  only  individual  who  can  request 
technical  assistance  from  SGI.  The  inexperienced  ISDN  administrator  fi'om  STL  has  to 
explain  the  problem  to  the  inexperienced  ISDN  administrator  in  Spanagel  Hall  who  in 
turn  will  explain  it  to  the  SGI  technical  representative.  Theoretically  a  solution  is 
provided.  In  practice  this  process  is  time  consuming  and  inefficient.  Following  SGI 
technical  support  recommendations,  an  SGI  operating  system  software  patch  was 
installed  that  fixed  the  bonding  problem  (SGI  Irix  5.3  patch  841).  Both  B  channels  then 
connected  and  similar  throughput  tests  were  performed  as  before.  A  3.7  MB 
uncompressed  executable  file  was  transferred  fi'om  steel  to  rambo.  The  ISDNstat 
window  showed  that  both  B  channels  were  connected  and  that  they  were  transmitting  110 
Kbps.  The  ftp  command  showed  that  the  effective  transfer  throughput  was  approximately 
164  Kbps.  Again  the  faster-than-maximum  speed  was  due  to  the  on-the-fly 
compression/decompression  in  the  ppp  software. 

The  next  step  was  to  precompress  the  file  so  that  there  would  be  no  compression 
in  the  transmission.  The  3.7  MB  executable  file  was  compressed  to  a  1.2  MB  file.  The 
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ISDNstat  displayed  that  each  channel  was  transmitting  at  54-56  Kbps.  The  results  were 
again  verified  by  using  the  ftp  command,  which  recorded  an  effective  throughput  of  105 
Kbps  which  corroborated  what  ISDNstat  was  reporting  and  confirmed  that  further  on-the- 
fly  compression  was  infeasible, 

3.  MBone  Testing 

Many  issues  came  up  when  trying  to  perform  multicasting  across  ISDN.  The  first 
issue  was  creating  a  tunnel  firom  rambo  to  steel.  The  multicast  routing  daemon  mrouted 
insists  that  there  be  more  than  one  virtual  interface  (viQ  before  it  runs.  A  vif  is  either  a 
real  physical  interface  or  an  encapsulated  multicast  tunnel.  Otherwise  mrouted  can  only 
send  the  multicast  packets  out  on  the  same  interface  as  they  came  in  on.  mrouted  is  just 
like  a  regular  router,  it  takes  packets  from  one  interface  and  sends  them  out  on  another 
interface. 

The  problem  is  that  the  pppO  interface  doesn’t  come  up  or  even  exist  until  ppp 
runs.  Setting  up  the  ppp  “interface”  is  one  of  the  things  that  the  ppp  command  does. 
Therefore,  a  vif  does  not  exist  prior  to  ppp  running.  The  pre-tunnel  error  message  is 
Appendix  D.  The  solution  to  this  problem  was  to  add  a  tunnel.  The  only  thing  this  did 
was  add  a  vif  which  allowed  mrouted  to  run. 

Another  multicast  issue  concerned  routing,  steel  is  dual-homed  with  FDDI  which 
has  multicast  on  it.  When  the  multicast  tools  were  run,  the  session  directory  came  up  on 
the  fiber  connection  and  not  on  the  ISDN.  We  did  not  want  to  change  the  routing 
daemons  (gated  and  routed)  because  we  were  not  familiar  with  ISDN  and  did  not  want 
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the  ISDN  line  to  fail.  Therefore,  in  order  to  test  multicast  running  across  ISDN  and  not 
fiber,  steel  would  have  to  be  disconnected  from  the  fiber  backbone.  We  did  not  want  to 
disconnect  steel  (for  other  reasons)  so  it  was  decided  to  use  baby  for  this  part  of  the  test. 

A  session  directory  (sdr)  was  established  on  baby,  rambo  could  not  see  the 
advertised  session.  The  audio  and  video  tools  (vie  and  vat)  were  used.  Nothing  appeared 
on  rambo 's  monitor,  but  ISDNStat  indicated  that  the  two  B  channels  were  connected  and 
that  rambo  was  receiving  data  at  1 10  Kbps. 

It  was  concluded  that  the  ISDN  line  was  configured  correctly  and  that  it  was 
transmitting  and  receiving  properly.  The  reason  why  the  session  directory  was  not  being 
advertised  on  the  Internet  must  be  due  to  an  MBone  configuration  problem  which  was 
above  the  level  of  the  system  administrator. 

Technical  support  at  SGI  reported  that  there  is  a  bug  in  the  ppp  software. 
Therefore,  the  ppp  software  does  not  support  multicasting.  This  information  is  contrary 
to  what  a  user  from  the  MBone  User’s  list  had  reported.  The  user  said  that  he  is  using 
SGI  with  Ascend  products  to  run  MBone  successfully.  It  is  possible  that  this  original 
user  employed  a  unicast  tunnel  for  MBone  connectivity  rather  then  passing  native 
multicast  IP  packets. 

E.  SUMMARY 

This  chapter  discusses  the  tortured  methodology  of  how  the  STL  in  Root  Hall  got 
an  ISDN  line.  It  discusses  the  setup  of  the  hardware  and  software.  It  also  discusses  the 
results  of  the  ISDN  multicast  experiments  and  possible  reasons  why  these  experiments 


failed.  The  results  of  the  experiment  determined  that  SGI  Indys  have  a  proprietary 
solution  to  MP  and  if  the  machines  at  each  end  of  the  ISDN  connection  are  Irufys,  then 
speeds  of  over  110  Kbps  (without  compression)  can  be  achieved.  Native  multicast 
support  was  not  successfully  demonstrated.  ISDN  line  reliability  is  inteimittent  despite 
exhaustive  troubleshooting. 

This  chapter  also  documents  the  frustrations  of  a  proficient  system  administrator 
who  is  inexperienced  with  ISDN  technology  and  has  no  available  means  to  get  timely, 
accurate  or  consistent  answers  to  questions  dealing  with  this  new  technology.  We 
believe  that  such  difiHculties  are  common  based  on  widespread  unfamiliarity  with  ISDN. 

ISDN  is  still  point-to-point.  Multicasting  with  ISDN  appears  to  be  unsupported, 
at  least  by  SGI  hardware  and  software.  The  technical  representatives  for  the  ISDN 
equipment  claim  to  have  bugs  in  their  ppp  software  that  prevents  it  from  performing 
multicasting.  However  some  MBone  users  claim  it  can  be  done  (Appendix  E). 
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vm.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  INTRODUCTION 

Installing  and  using  a  new  technology  can  become  quite  an  arduous  task, 
especially  if  a  new  user  does  not  have  a  technical  background.  Section  B  discusses  the 
issues  surrounding  the  failure  of  extending  LAN  connectivity  using  ISDN.  Section  C 
presents  the  results  of  this  case  study.  Section  D  discusses  recommendations  to  resolve 
these  issues.  Section  E  presents  recommendations  for  fiiture  work. 

B.  INSTALLATION  ISSUES 

It  is  difficult  to  obtain  technical  help  because  ISDN  support  crosses  too  many 
organizational  boundaries.  PacBell  sells  the  user  the  ISDN  line.  The  technician  that 
installs  the  line  may  not  know  anything  about  the  technology  itself  except  how  to  install 
the  line  and  how  to  test  that  it  is  coimected.  The  information  about  the  technology  is 
obtained  from  the  salesperson  who  is  quoting  from  the  media  literature  (which  is  not 
correct).^  No  confirmation  of  PacBell’s  ISDN  equipment  and  specifications  is  performed. 


^We  called  PacBell  and  talked  to  a  sales  representative  who  said  that  their  ISDN 
was  2B+D  and  that  the  B  channels  were  capable  of  speeds  up  to  64  Kbps.  When  asked 
about  the  switch  software,  she  didn’t  know  what  we  were  talking  about.  She  put  us  on 
hold  for  five  minutes  and  came  back  and  said  the  software  was  National  ISDN  and  not 
Custom.  NPS  Base  Communications  spoke  with  their  PacBell  technical  representative 
who  said  that  all  their  switches  in  Monterey  were  Custom. 
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Another  organizational  boundary  is  the  vendor  of  the  NT  1 .  This  technician  needs 
to  know  how  the  NTl  works  with  the  TEl  or  TE2  (which  might  be  yet  another  vendor). 
The  technician  also  needs  to  know  how  the  NTl  works  with  the  ISDN  line  (U  interface). 

The  next  organbational  boundary  is  the  vendor  of  the  TEl .  This  is  not  necessarily 
the  same  vendor  as  the  NTl.  The  technician’s  responsibility  is  to  know  how  the  software 
configuration  works  with  the  CO  switch  and  the  interaction  with  the  NTl. 

Given  the  many  problems  reported  in  the  Experimental  Results  chapter,  each 
organizational  entity  was  quick  to  point  fingers  at  the  other.  Both  PacBell  and  NFS  Base 
Communications  questioned  whether  the  ppp  software  was  configured  properly. 

Hardware  vendors  of  the  equipment  blamed  problems  on  the  switch  software.  The  end 
result  is  that  the  user  does  not  receive  timely  technical  help  which  exacerbates  the 
problem.  We  expect  that  most  sites  would  have  cancelled  the  entire  connection.  We  are 
persevering  to  continue  testing  this  technology  despite  the  fact  that  many  problems 
(including  line  reliability)  are  unresolved. 

Another  issue  which  created  a  problem  in  this  case  study  is  the  organizational 
structure  of  NPS  and  interaction  between  the  individual  departments  of  the  organization. 
NPS  Base  Communication  is  a  tenant  command.  They  are  responsible  for  all 
communications  within  the  NPS  campus.  When  a  user  puts  in  a  work  request  to  Base 
Communications,  it  is  prioritized  based  on  work  for  other  users  within  this  organization. 
The  job  request  is  considered  closed  once  the  work  is  performed  and  the  line  is  installed. 

If  the  user  is  having  problems  getting  that  line  to  work,  another  work  request  is  generated 
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to  have  the  line  tested.  Again,  this  new  work  request  is  prioritized  based  on  other  work  of 
other  users.  Satisfectory  testing  must  be  a  condition  for  completion  of  work. 

Suprisingly,  the  user  who  is  using  the  technology  is  not  considered  the  customer  of 
the  service  provider.  NPS  Base  Communications  is  the  official  customer.  Therefore,  the 
user  caimot  acquire  technical  help  directly  from  PacBell.  The  request  for  technical  help 
has  to  be  initiated  through  NPS  Base  Communications.^  This  situation  is  unsatisfactory. 

Getting  technical  help  from  vendors  about  ISDN  equipment  is  also  a  complex 
issue.  The  maintenance  agreement  for  SGI  equipment  has  one  point  of  contact  for  the 
entire  school.  This  individual  is  outside  the  department  requesting  the  technical  help.  This 
causes  a  problem  because  a  second  party  gets  involved  who  relays  the  information  to  the 
vendor.  Sometimes  the  detailed  complexity  of  the  issue  gets  lost  in  the  translation.  This 
causes  additional  problems  and  compounds  the  difficulties  experienced. 

This  experiment  attempted  to  cormect  a  workstation  within  Root  Hall  to  another 
workstation  outside  of  the  boundaries  of  Root  Hall.  This  was  the  simplest  possible 
realistic  test  we  could  devise.  However  this  meant  getting  another  system  administrator 
involved.  This  can  cause  a  problem  because  an  agreement  has  to  made  prior  to  the 
experiment  to  make  the  project  a  responsibility  for  both  system  administrators.  Often 
projects  that  are  not  the  responsibility  of  both  departments,  get  pushed  to  the  end  of  the 
job  priority  list. 

^ase  Communications  at  the  time  of  this  writing  did  not  have  a  technician 
experienced  with  ISDN.  ISDN  training  is  planned  for  one  technician.  Additional  training 
for  a  second  individual  is  recommended. 
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When  doing  a  technical  thesis,  the  student  has  to  rely  on  the  system  administrator 
of  that  department  for  assistance.  The  system  administrator  is  the  superuser  for  the 
network  and  is  the  only  one  who  can  make  changes  to  the  network.  This  was  an  issue  in 
this  case  study  because  there  were  many  students  who  needed  administrator  assistance. 
The  administrator  has  other  duties  and  responsibilities  and  it  becomes  very  difficult  to 
schedule  priorities.  The  problem  is  compounded  when  crossing  organizational  boundaries 
because  now  the  student  is  dependant  on  two  system  administrators  and  not  one. 

Frequent  coordination  and  patience  are  essential. 

C.  EXPERIMENTAL  RESULTS 

It  was  experimentally  verified  that  ISDN  provides  a  bandwidth  up  to  1 12  Kbps. 
However  it  was  not  experimentally  confirmed  whether  the  switch  supports  a  full  128  Kbps 
(2  B  channels  at  64  Kbps  each).  It  appears  that  our  link  supports  1 12  Kbps  (2  B  channels 
at  56  Kbps  each).  Additionally  it  was  determined  that  ISDN  is  not  a  completely  reliable 
technology  because  the  line  continues  to  fail  and  diagnostic  efforts  have  been  inconclusive. 

All  tests  to  determine  whether  ISDN  supports  native  IP  multicasting  were 
negative.  An  SGI  technical  representative  said  that  there  is  a  bug  in  the ppp  software 
which  causes  their  ISDN  solution  to  not  support  multicasting.  However  an  individual 
from  the  MBone  Users  Group  stated  that  he  uses  SGIs  with  Ascend  products  and  it 
supports  multicasting.  His  solution  and  others  are  attached  as  Appendix  E.  Their  results 
each  use  unicast  tunnels  over  ISDN  to  provide  multicast  at  each  end.  This  is  consistent 
with  the  results  found  in  this  thesis. 
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D.  RECOMMENDATIONS  FOR  IMMEDIATE  ACTION 


When  dealing  with  a  new  technology,  one  person  should  be  in  charge  of  the  whole 
process.  The  individual  should  be  responsible  for  buying  the  phone  lines,  buying  the  ISDN 
equipment  and  having  superuser  privileges  on  both  ends  of  the  link.  Crossing 
organizational  boundaries  only  creates  problems.  If  NFS  Base  Communications  is 
responsible  for  all  communication  technology,  then  their  technicians  need  to  be  properly 
trained  and  capable  of  answering  user’s  questions.  NFS  Base  Communications  needs  to 
obtain  documentation  from  the  ISDN  service  provider  pertaining  to  the  information 
necessary  to  make  the  ISDN  equipment  compatible  with  the  service  provider’s  equipment. 
All  installations  (regardless  of  technology)  should  be  coordinated  prior  to  the  setup  date  in 
order  to  have  all  responsible  individuals  present  so  that  questions  can  be  answered.  NFS 
Base  Communications  must  not  consider  a  work  request  closed  unless  the  technology  is 
working  properly.  We  recommend  that  NFS  Base  Communications  correct  these 
problems. 

To  achieve  success  using  ISDN,  the  responsible  individual  should  choose  an  ISDN 
solution  with  the  largest  market  share,  or  contract  a  consultant  to  buy  an  interoperable 
package.  This  consultant  is  a  liaison  between  the  ISDN  service  provider,  hardware  and 
software  providers.  The  consultant  is  responsible  for  maintenance  and  training  support  as 
well  as  a  working  product.  We  recommend  training  two  NFS  technical  staff  members  to 
become  as  proficient  as  an  ISDN  consultant  in  these  areas. 
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More  system  administrators  need  to  be  employed  if  assisting  students  with  thesis 
work  is  a  priority.  There  are  too  many  students  with  technical  theses  and  too  many  other 
user  requirements  that  need  the  support  of  three  STL  system  administrators  in  Root  Hall. 
More  administrators  are  needed.^ 

A  visit  to  the  local  PacBell  office,  visual  inspection  of  the  ISDN  switching 
equipment  and  dialog  with  the  cogni2ant  technical  expert  will  likely  resolve  many  of  these 
open  issues.  Of  particular  interest  is  the  means  by  which  PacBell  diagnoses  line  problems. 
E.  RECOMMENDATIONS  FOR  FUTURE  WORK 

When  the  issues  of  reliability,  capacity  and  multicast  compatibility  are  resolved, 
ISDN  needs  to  be  evaluated  again  to  determine  if  it  is  a  viable  solution  to  extending  LAN 
coimectivity.  Specifically,  ISDN  needs  to  be  tested  across  diflferent  operating  system 
platforms  to  determine  interoperability  especially  when  dealing  with  MP.  National  and 
global  ISDN  standards  still  need  to  be  tested  to  also  determine  interoperability  issues. 
ISDN  needs  to  be  tested  for  long  distance  and  international  telecommuting.  The  final 
issue  is  multicasting.  Although  this  thesis  successfially  demonstrated  IP  over  ISDN, 
multicast  usability  needs  to  be  verified.  This  includes  remote  LAN  monitoring  firom  home 
to  include  network  monitoring  pages  (Edwards,  96)  (Erdogan,  96).  Once  this  is 
successfully  accomplished,  it  is  recommended  that  STL  purchase  the  ISDN  technology 
and  ISDN  equipment  for  system  administrative  security  reasons  as  well  as  to  test 
telecommuting  effectiveness. 

^Further  hiring  actions  are  in  progress  to  correct  this  situation. 


New  technologies,  need  to  be  evaluated  after  they  enter  the  marketplace  to  verify 
that  the  technology  does  everything  that  the  specifications  say  it  does.  Information 
Technology  managers  need  to  carefully  test  products  and  analyze  them  thoroughly  before 
making  a  decision  to  use  it.  Buying  into  media  hype  and  marketing  promises  will  often 
pull  the  manager  in  the  wrong  direction  and  possibly  cost  more  money.  It  is  the 
responsibility  of  the  Information  Technology  manager  to  examine  new  technologies  and 
find  the  one  that  best  suits  the  organizations  needs,  infrastructure  and  future  plans. 

F.  CONCLUSION 

Although  this  experiment  to  test  ISDN  was  only  partially  successful,  there  were 
many  technical  and  managerial  lessons  learned  which  can  be  taken  away  from  this  case 
study.  DoD  must  make  a  concerted  effort  to  evaluate  both  ongoing  and  future  programs 
which  will  implement  new  technology  in  order  to  ensure  that  the  technology  increases 
mission  capability  in  the  most  beneficial  and  cost  effective  manner.  Information 
Technology  managers  have  a  responsibility  to  make  intelligent  recommendations  based  on 
fact  and  not  media  hype.  Finally,  ISDN  capabilities  have  progressed  since  the  three  fatal 
showstoppers  identified  in  (Bigelow,  96).  The  corrections  are  not  yet  complete  however. 
We  remain  optimistic  that  ISDN  will  mature  into  a  data  link  technology  capable  of 
effectively  extending  Intemet-compatable  LAN  connectivity. 
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APPENDIX  A 


INTENATIONAL  DATA  CORPORATION’S  1995  TELECOM  MANAGERS 

SURVEY 


N  =  218 

Source:  International  Data  Corporation's  1995  Telecom  Managers  Survey 


Respondents'  Number  of  Connecbons  per  Telecom  Service 


- ^ ^ ^ - ,  I 

Basic  Exchange  Private  Lines  Switched  56  BRIISON  PRllSDN  Other 


B  0  Median 

1  =  218 

lource:  Intematiofial  Data  Corporation's  1995  Telecom  Managers  Survey _ 


From  (Shapiro/Robertson,  95). 
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APPENDIX  B 


ISDN  BASIC  RATES  IN  THE  UNITED  STATES 


Ameritech 


Service 

Monthly 

Installation 

Minutes 

Included 

Per  Add’l 

Minute 

Illinois 

Residential 

28.19 

135.00 

local  rates 

Michigan 

Residential 

33.51 

122.00 

local  rates 

Ohio 

Residential 

32.20 

116.50 

local  rates 

Wisconsin 

Residential 

30.90 

113.05 

local  rates 

Illinois 

Business 

33.60 

132.35 

local  rates 

Michigan 

Business 

37.46 

147.00 

local  rates 

Ohio  Business 

40.60 

129.35 

local  rates 

Wisconsin 

Business 

37.00 

100.65 

local  rates 

Bell  Atlantic 


Business  ISDN 

41.88 

125.00 

.02/.01+ 

Residential 

34.00 

125.00 

.02/.01+ 

Available  at  http://www.xmission.com/isdncomp.html 
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NYNEX 


Service 

Monthly 

Installation 

Minutes 

Included 

Per  Add’l 

Minute 

Residential 

28.35 

57.57 

local  rate 

Pacific  Bell 


ISDN 

24.82 

70.75* 

local  rate 

Southwestern  Bell 


10  Hours 

45.50 

52.25* 

600 

.04 

80  Hours 

63.50 

52.25* 

4800 

.02 

US  West 


Arizona 

69.00 

110.00 

1200 

.02 

Colorado 

60.00 

67.00 

unlimited 

Oregon 

69.00 

110.00 

1200 

.03 

Washington 

35.00 

85.00 

0 

.04/.015++ 

Washington 

50.00 

85.00 

2400 

.04/.015-H- 

Washington 

63.00 

85.00 

unlimited 

Utah  (proposed 

1 

Basic 

39.00 

110.00 

0 

.03 

200  Hour 

68.00 

110.00 

12000 

.03 

Flat 

184.00 

110.00 

unlimited 

*Iarger  installation  fee  waived  with  minimum  service 
+day/night 

++first  minute/additional  minutes 

Available  at  http://www.xmission.com/isdncomp.html 
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APPENDIX  C 


DEBUGGING  SCRIPT  FOR  ISDN  PPP  SOFTWARE  OUTPUT 


ppp  [1666]  : 

PPP [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 

ppp  [1666]  : 
ppp  [1666]  : 

ppp  [1666]  : 
ppp  [1666]  : 

ppp  [1666]  : 
ppp  [1666]  : 
ppp  [1666]  : 
ppp  [1666]  : 
ppp [1666]  : 

ppp  [1666]  : 
ppp [1666] : 


rambo  IPCP2:  Req-Sent (6) ->Starting (1) 
rambo  LCP2:  send  Configure -Request  ID=Oxfl 
rambo  LCP2:  magic=Ox6907cl8f 

rambo  LCP2 :  receive  compressed  protocol  field 
rambo  2;  send  Oxc  bytes:  index=ll  proto=0xc021  01 
fl  00  Oc  05  06  69  C 

rambo  LCP2:  send  Conf igure-ACK  ID=Ox7a 

rambo  2:  send  0x16  bytes:  index=ll  proto=Oxc021 

02  7a  00  16  01  04  05 

rambo  LCP2:  Opened (9 ) - >Ack-Sent (8) 

rambo  2:  read  Oxc  bytes:  proto=Oxc021  02  fl  00  Oc 

05  06  69  07  cl  8f  C 

rambo  LCP2 :  receive  Conf igure-ACK  ID=Oxfl 

rambo  LCP2 :  event  RCA 

rambo  LCP2 :  action  TLU 

rambo  LCP2 :  MTU=1500  MRU=1500  TOS 

rambo  LCP2:  my  magic=Ox6907cl8f , his=Ox6907991f 

sync 

rambo  2:  entering  Authenticate  Phase 

rambo  AUTH2 :  will  send  PAP  requests  but  receive 

no  authentication 
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ppp [1666]  : 
ppp  [1666]  : 

ppp [1666]  : 
ppp [1666]  : 

ppp [1666]  : 

ppp [1666]  : 

ppp [1666]  : 

ppp [1666]  : 
ppp [1666]  : 

ppp [1666]  : 
ppp  [1666]  : 
ppp [1666] : 

ppp [1666] : 
ppp [1666] : 

ppp [1666] : 
ppp [1666] : 


raitibo  AUTH2 :  send  PAP  request  ID=Ox89 

rambo  2:  send  0x11  bytes:  index=ll  proto=0xc023 

01  89  00  11  04  "baby' ) 

rambo  LCP2 :  Ack-Sent (8) ->Opened(9) 

rambo  2:  read  0x10  bytes:  proto=Ox8021  01  05  00 

10  02  06  00  2d  10  00 

rambo  IPCP2:  discard  Configure -Request  because  in 
Authenticate,  not 

rambo  2:  read  0x11  bytes:  proto=0xc023  02  89  00 

11  Oc  "why  is  this?" 

rambo  AUTH2:  receive  PAP  Ack  ID=Ox89  containing 
"why  is  this?" 

rambo  2 :  entering  Network  Phase 
rambo  LCP2:  set  sync,  acomp=0,  pcomp=0, 
rx_ACCM=  0 ,  t x=0 , pad=  0 
rambo  IPCP2 :  event  Up 

rambo  IPCP2 :  send  Configure -Request  ID=Oxda 
rambo  IPCP2 :  16  slot  VJ  compression  without 
compressed  slot  IDs 

rambo  IPCP2 :  ADDR  our  address  131.120.7.116 
rambo  2:  send  0x10  bytes:  index=ll  proto=0x8021 
01  da  00  10  02  06  00 

rambo  IPCP2 :  Starting (1) - >Req -Sent (6) 

rambo  2:  read  0x10  bytes:  proto=Ox8021  02  da  00 

10  02  06  00  2d  Of  00 
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ppp[1666]:  rambo  IPCP2:  receive  Conf igure-Ack  ID=Oxda 
ppp[1666]  :  rainbo  IPCP2 :  event  RCA 
ppp[1666]:  rambo  IPCP2 :  Req-Sent (6) ->Ack-Rcvd(7) 
ppp[1666]:  rambo  IPCP2 :  event  T0+  #0 

ppp[1666]:  rambo  IPCP2 ;  send  Conf igure- Request  ID=0xdb 
ppp[1666]:  rambo  IPCP2 ;  16  slot  VJ  compression  without 
compressed  slot  IDs 

ppp[1666] :  rambo  IPCP2 :  ADDR  our  address  131.120.7.116 
ppp[1666]:  rambo  2:  send  0x10  bytes:  index=ll  proto=0x8021 
01  db  00  10  02  06  00 

ppp[1666]:  rambo  IPCP2 :  Ack-Rcvd(7) ->Req-Sent (6) 
ppp[1666]:  rambo  2;  read  0x10  bytes:  proto=Ox8021  02  db  00 
10  02  06  00  2d  Of  00 

ppp[1666]:  rambo  IPCP2 :  receive  Conf igure-Ack  ID=0xdb 
ppp[1666]:  rambo  IPCP2 :  event  RCA 

ppp[1666]:  rambo  IPCP2 :  Req-Sent (6) ->Ack-Rcvd (7) 
ppp[1666]:  rambo  IPCP2 :  event  T0+  #0 

ppp[1666]:  rambo  IPCP2 :  send  Conf igure -Request  ID=0xdc 
ppp[1666]:  rambo  IPCP2 :  16  slot  VJ  compression  without 
compressed  slot  Ids 

ppp[1666]:  rambo  IPCP2 :  ADDR  our  address  131.120.7.116 
ppp[1666]:  rambo  2:  send  0x10  bytes:  index=ll  proto=0x8021 
01  dc  00  10  02  06  00 

ppp[1666]:  rambo  IPCP2 :  Ack-Rcvd (7) - >Req-Sent (6) 
ppp[1666]:  rambo  2:  read  0x10  bytes:  proto=0x8021  02  dc  00 
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ppp [1666] 
ppp [1666] 
ppp [1666] 
ppp [1666] 

ppp [1666] : 
ppp [1666]  : 

ppp  [1666]  : 

ppp  [1666]  : 
ppp  [1666]  : 
ppp [1666] : 

ppp [1666] : 
ppp [1666] : 
ppp [1666] : 

ppp [1666]  : 

ppp [1666]  : 
ppp [1666]  : 
ppp  [1666]  : 
ppp [1666] : 


10  02  06  00  2d  Of  00 

rambo  IPCP2:  receive  Configure -Ack  ID=Oxdc 

rambo  IPCP2 :  event  RCA 

rambo  IPCP2:  Req-Sent (6) - >Ack-Rcvd (7) 

rambo  2:  read  0x10  bytes:  proto=Ox8021  01  06  00 

10  02  06  00  2d  10  00 

rambo  IPCP2:  receive  Configure -Request  ID=Ox6 
rambo  IPCP2:  accept  17  slot  VJ  header  compression 
(but  use  16)  wit 

rambo  IPCP2:  accept  its  address  131.120.7.49  from 

ADDR  Request 

rambo  IPCP2 :  event  RCR+ 

rambo  IPCP2 :  send  Conf igure-ACK  ID=Ox6 
rambo  2:  send  0x10  bytes:  index=ll  proto=Ox8021 
02  06  00  10  02  06  00 
rambo  IPCP2 :  action  TLU 
rambo  IPCP2 :  Ack-Rcvd (7) - >Opened (9 ) 
rambo  IPCP2:  ready  131.120.7.116  to  131.120.7.49, 
rx_vj_comp=y, tx=y  r 

rambo  LCP2 :  set  sync,  acomp=0,  pcomp=0, 

rx_ACCM=  0 ,  t x= 0 , pad=  0 

rambo  CCP2 :  event  Open 

rambo  CCP2 :  action  TLS 

rambo  CCP2:  Initial (0) ->Starting (1) 

rambo  CCP2:  event  Up 
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ppp[1666]  :  raiiibo  CCP2:  send  Configure -Request  ID=0xe3  for  12 
bit  BSD  Compress  a 

ppp[1666]:  rambo  2:  send  0x9  bytes:  index=ll  proto=Ox80fd  01 
e3  00  09  15  03  2c  0 

ppp [1666] : rambo  CCP2:  Starting (1) - >Req-Sent (6) 
ppp[1666]:  rambo  2:  read  0x7  bytes:  proto=0x80fd  01  46  00  07 
15  03  2c 

ppp [1666]:  rambo  CCP2:  receive  Configure -Request  ID=0  ~46 
ppp [1666]:  rambo  CCP2:  turn  off  TX  compression 
ppp  [1666]:  rambo  CCP2 :  accept  12  bit  BSD  compression 
ppp [1666]:  rambo  CCP2:  event  RCR+ 

ppp[1666]:  rambo  CCP2:  send  Conf igure-ACK  ID=Ox46 
ppp [1666]:  rambo  2:  send  0x7  bytes:  index=ll  proto=Ox80fd  02 
46  00  07  15  03  2c 

ppp [1666]:  rambo  CCP2:  turn  on/reset  TX  12  bit  BSD  Compress 
ppp[1666]:  rambo  CCP2:  Req-Sent  (6) ->Ack;-Sent  (8) 
ppp[1666]:  rambo  2:  read  0x7  bytes:  proto=Ox80fd  02  e3  00  07 
15  03  2c 

ppp [1666]:  rambo  CCP2 :  receive  Conf igure-ACK  ID=Oxe3 

ppp [1666]:  rambo  CCP2 :  turn  on/reset  RX  12  bit  BSD  Compress 

ppp [1666]:  rambo  CCP2:  event  RCA 

ppp [1666] :  rambo  CCP2 :  action  TLU 

ppp[1666]:  rambo  CCP2 :  Ack-Sent (8) ->0pened(9) 

ppp[1666]:  rambo:  TCP/IP  activity:  busy 

ppp[1666]:  rambo:  TCP/IP  activity:  busy 
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ppp[l666]:  raitibo:  TCP/IP  activity:  busy 
ppp[1666]:  rainbo:  TCP/IP  activity:  busy 
ppp[1666]:  rambo:  TCP/IP  activity:  busy 
ppp[1666]:  rambo:  TCP/IP  activity:  busy 
ppp[1666]:  rambo:  TCP/IP  activity:  busy 
ppp[1666]:  rambo:  TCP/IP  activity:  busy 
ppp[1666] :  rambo:  TCP/IP  activity:  busy 
ppp[1666] :  rambo:  TCP/IP  activity:  busy 
ppp[1666]:  rambo:  TCP/IP  activity:  busy 
ppp[1666] :  rambo:  TCP/IP  activity:  busy 
ppp[1666] :  rambo:  TCP/IP  activity:  busy 
ppp[1666] :  rambo:  TCP/IP  activity:  busy 
ppp[1666]:  rambo:  TCP/IP  activity:  moderate 
ppp[1666] :  rambo:  TCP/IP  activity:  busy 
ppp[1666]:  rambo:  TCP/IP  activity:  busy 
ppp[1666]:  rambo:  TCP/IP  activity:  moderate 

ppp[1666]:  rambo  2:  read  0x4  bytes:  proto=Ox80fd  Oe  47  00  04 
ppp[1666]:  rambo  CCP2 :  receive  Reset-Request  ID=Ox47 
ppp[1666]:  rainbo  CCP2 :  send  Reset-Ack  ID=0x47 
ppp[1666] :  rambo  2;  send  0x4  bytes:  index=ll  proto=0x80fd  Of 
47  00  04 

ppp[1666] :  rambo  CCP2 :  turn  on/reset  TX  12  bit  BSD  Compress 
ppp[1666] :  rambo  2:  read  0x4  bytes:  proto=Ox80fd  Oe  48  00  04 
ppp[1666]:  rambo  CCP2 :  receive  Reset-Reguest  ID=Ox48 
ppp[1666]:  rambo  CCP2 :  send  Reset-Ack  ID=0x48 


ppp[1666]:  rambo  2:  send  0x4  bytes:  index=ll  proto=0x80fd  Of 
48  00  04 

ppp[1666]:  rambo  CCP2:  turn  on/reset  TX  12  bit  BSD  Compress 

ppp[1666]:  rambo:  TCP/IP  activity:  low 

ppp[1666]:  rambo:  TCP/IP  activity:  low 

ppp[1666]:  rambo:  TCP/IP  activity:  moderate 

ppp[1666]:  rambo:  TCP/IP  activity:  busy 

ppp[1666] :  rambo:  TCP/IP  activity:  busy 

ppp[l666]:  rambo:  TCP/IP  activity:  busy 

ppp[1666]:  rambo:  TCP/IP  activity:  busy 

ppp[1666] :  rambo:  TCP/IP  activity:  busy 

ppp[1666]:  rambo:  TCP/IP  activity:  busy 

ppp[1666]:  rambo:  TCP/IP  activity:  busy 

ppp[1666]:  rambo:  TCP/IP  activity:  busy 

ppp[1666]:  rambo:  TCP/IP  activity:  moderate 

ppp[1666]:  rambo  2:  inactivity  timeout;  /dev/isdn/modem_b2 

ppp[1666]:  rambo  LCP2 :  event  Close 

ppp[1666]:  rambo  LCP2 :  send  Terminate -Request  ID=0xf2 
"inactivity  timeout" 

ppp[1666]:  rambo  2:  send  0x16  bytes:  index=ll  proto=0xc021 
05  f2  00  16  "inactivi 
ppp[1666]:  rambo  LCP2 :  action  TLD 
ppp[1666]:  rambo  IPCP2 :  event  Down 
ppp[1666]:  rambo  IPCP2 :  action  TLD 
ppp[1666]:  rambo  IPCP2 :  Opened (9) ->Starting (1) 
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ppp  [1666]  : 
ppp [1666]  ; 
ppp [1666]  : 
ppp  [1666]  : 
ppp [1666]  : 
ppp  [1666]  : 

ppp [1666]  : 

ppp [1666]  : 
ppp  [1666]  : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 


rambo  CCP2 :  event  Down 

rambo  CCP2 :  action  TLD 

rambo  CCP2 :  Opened (9) ->S tart ing (1) 

rambo  LCP2:  Opened (9 ) ->C1 os ing (4) 

rambo  2 :  entering  Terminate  Phase 

rambo  2:  read  0x16  bytes:  proto=0xc021  06  f2  00 

16  "inactivity  timeo- 

rambo  LCP2:  receive  Terminate -Ack:  06  f2  00  16 

"inactivity  timeout" 

rambo  LCP2 :  event  RTA 

rambo  LCP2 :  action  TLF 

rambo  2 :  entering  Dead  Phase 

rambo:  Closing (4) ->Initial (0) 

rambo:  TCP/IP  activity:  low 

rambo:  TCP/IP  activity:  low 

rambo  1:  line  off: 

rambo  1:  /dev/isdn/modem_bl  off 

+  route  delete  default  131.120.7.49 

delete  net  default:  gateway  131.120.7.49 

rambo:  exiting  with  0 
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APPENDIX  D 


DEBUGGING  SCRIPT  FOR  PRE-TUNNEL  ERROR  MESSAGE 

rainbo  1#  /uer/etc/mrouted  -d 
debug  level  2 

11:26:01.511  mrouted  version  3.8 

11:26:01.633  Getting  vifs  from  kernel  interfaces 
11:26:01.634  installing  ecO  (131.120.7.49  on  subnet 
131.120.7/24)  as  vif  #0  -  ra 
11:26:01.635  Getting  vifs  from  /etc/mrouted. conf 
11:26:01.677  can't  forward:  only  one  enabled  vif 

AAAAAAAAAAAAAAAAAAAA 
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APPENDIX  E 


E-MAIL  FROM  MBONE  USERS 

Date:  Thu,  3 1  Aug  1 995  09:44: 1 1  PDT 
From:  Bill  Fenner  <fenner@parc.xerx.com> 

To:  Davidwfox@eworld.com 
CC:  rem-conf@es.net 
Subject:  Re:  ISDN  &  M-Bone 

In  message  <950830154851_14I64706@eWorld.com>  you  write: 

>Just  about  to  install  128k  ISDN  connected  to  Mac  server  network  in  our  home.  Will  we 
be  able  to  connect  to  the  M-Bone  and  if  so,  what  special  equipment  do  we  need?< 

I  occasionally  run  a  tunnel  over  my  ISDN  link,  it  works  very  well  for  audio  and  if  you  do 
priority  dropping  you  can  get  some  vague  idea  of  what  the  video  is  supposed  to  look  like. 
You  need  a  multicast  capable  router  at  your  home.  I’m  pretty  sure  that  MacTCP  doesn’t 
do  multicast  forwarding;  I  don’t  know  if  MachTen  does  or  not.  You  might  need  to  find  a 
UNIX  box  (e.g.  a  cheap  PC  running  FreeBSD)  to  put  at  your  end.  Or,  if  the  ends  of  the 
ISDN  line  are  real  routers,  (as  opposed  to  a  bridge),  you  might  be  able  to  turn  on 
multicast  forwarding  on  them.  Bill 
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Date:  Sun,  28  Aug  1994  20:20:49  +0900 

From:  Hitoaki  Sakamoto  <hitoaki@sphere.csl.ntt.jp> 

To:  rem-conf@es.net,  MBONE@isi.edu 
Subject:  Re:  ISDN,  PPP,  and  MBONE 

<Does  anyone  know  of  someone  using  ISDN  to  support  an  MBONE  connection?  I 
would  be  particularly  interested  to  know  if  anyone  is  using  an  SGI  Indy  or  Sun  ( which 
have  a  ISDN  port)  with  ISDN  for  MBONE  use.> 

I  am  using  the  MBONE  with  ISDN  at  home.  I  have  a  Sun  IPX  with  ISDN  S-bus 
board  (from  CSR,  not  SUN  original).  This  board  is  very  useful,  because  it  can  use  2  B 
ch  (128  Kbps). 


Date:  Sat,  27  Aug  1994  22:22:31  -0700 
From:  Paul  Traina  <pst@cisco.com> 

To:  Michael  Macedonia<macedoni@fravyl.cs.nps.navy.mil> 

Cc:  MBONE@ISI.EDU 

Subject:  Re:  ISDN,  PPP,  and  MBONE 

<Does  anyone  know  of  someone  using  ISDN  to  support  an  MBONE  connection?> 

Yes,  I  am  using  PPP  over  ISDN,  however  I’m  using  PIM/sparse  as  opposed  to  DVMRP 
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to  carry  my  routing  information.  DVMRP  (and  PIM/dense)  is  not  well  suited  to  using  a 
low  bandwidth  link  with  a  low  threshold  limit  (as  an  example,  a  link  between  work  and  a 
telecomuter  at  home  who  want’s  to  receive  local  work  multicast  transmissions)  because 
you  get  periodic  blasts  of  multicast  traffic  until  your  prune  messages  get  back  (assuming 
you  have  a  mrouted  that  listens  to  prunes  at  all).  Before  I  switched  to  using  PM  in 
sparse  mode,  every  time  a  prune  message  would  expire.  I’d  get  a  blast  of  packets  down 
my  link  until  the  packets  were  processed  and  a  prune  message  was  sent  back.  Now  you’d 
tend  to  think  that  this  should  happen  really  fast,  and  it  does,  but  it’s  really  annoying  to 
see  that  1  second  freeze  every  n  seconds. 


Return-Path;  <e93_mda@it.kth.se> 

To:  lrmihlon@nps.navy.niil  (Lauren  R  Mihlon) 

CC;  magda@it.kth.se,  e93_mda@it.kth.se 
Subject:  Re:  ISDN  and  MBONE 
Date:  Tue,  09  Jul  1996  22:57:36  +0200 
From:  Magnus  Danielson<e93_mda@it.kth.se> 

Hi!  I  think  that  the  tech  support  was  wrong  or  at  least  slightly  wrong.  Now,  this  is  how  I 
be.,  bring  MBONE  to  my  home  Indy  over  ISDN: 

1)  I  run  Irix  5.3 

2)  I  have  patched  it  with  the  multicast  routing  patch  that  is  freely  available  from  SGI. 

The  kernel  patch  is  for  mrouted  3.5  and  above  and  you  also  get  an  mrouted  3.8  along 
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with  it. 


3)  I  have  patched  the  OS  with  the  ISDN  patch. 

4)  I  have  configured  it  to  do  2  X  64  Kbps  which  is  supported. 

5)  In  the  other  end  I  have  an  Ascend  primary-rate  box. 

6)  I  have  a  mrouted  multicast  router  in  the  other  end. 

7)  I  configure  a  multicast  tunnel  between  my  box  and  the  multicast  router. 

5.5)  My  Indy  has  its  own  IP  number  space! ! ! 

8)  The  address  space  is  split  so  that  a  4  address  range  ( this  is  called  /30  for  the  netmask... 
I  wiU  use  that  term  from  this  point)  is  dedicated  to  the  ISDN  line.  The  Ascend  has  the 
lower  address  and  the  Indy  has  the  higher  (  or  the  other  way  around.,  doesn’t  really 
matter)  like  this: 

x.x.x.  112  lower  broadcast 
x.x.x,  113  Indy  ISDN  port 
x.x.x.  1 14  Ascend  ISDN  port 
x.x.x.  115  upper  broadcast 

These  numbers  shows  the  real  layout  of  my  box  and  the  base 
x.x.x.  1 12  may  be  changed  to  whatever  you  like. 

Now,  the  Indy  ethemet  port  MUST  be  on  another  subnet  than  the  ISDN  port  in  order  to 
allow  mrouted  to  route  traffic.  This  network  might  be  as  small  as  a  /30  or  bigger...  so 
you  can  let  the  Indy  route  traffic  to  other  machines. 

9)  I  use  both  sd,  vie  and  vat  with  success.  Wb  also  runs  great  once  you  have  learned  to 
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avoid  the  x  server  postscript  bug.  Last  time  I  tried  to  use  sd  I  did  have  trouble.but  on  the 
other  hand  was  the  MBONE  pretty  upset  that  day  so  I  went  for  a  point-to-point  thing 
instead. 

I  do  recommend  you  to  run  the  SNMP  mrouted  in  both  ends  and  learn  to  use  the  tools, 
my  home  Indy  was  the  Indy  I  did  my  half  of  the  SNMP  mrouted  port  on. 

Good  luck  Magnus 
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